Application Design Question

[mrpubnight]

Hello everyone I'm hoping someone with more experience can suggest how
I would go about designing the following:

We have a standard web application and in its current form there are no
distinct layers. Everything is jumbled together. In an effort to
deploy new code in a more structured manner I've decided to break apart
the UI from the Business (no big stretch here). I have a data access
class in my business layer which is obviously called frequently.

We're using mulitple databases and thus have multiple connection
strings encoded in web.config. The data class I'm building now
retrieves the various connection strings and then depending on the use
a certain connection object is instantiated.

So far so good - no major issues here, however, rather than always
going to web.config (or AppSettings) and iterating through all the
AppSettings to find the connection strings seems silly so I chose to
iterate through them the first time the data class is called and then
store the list in cache which each subsequent instantiation calls.

My dimlema now is more one of design principle rather than a technical
problem. If my data class calls into the System.Web.Cache and I want
to get a current instance of the web application then in a sense I'm
starting to mix my layers again (aren't I).

Is it regarded as poor practice to 'touch' the HttpApplication object
from the business layer? It seems that the HttpApplication object
lives in the presentation layer and as such so does the cache. Am I
being too fussy about breaking apart my layers given that this is a web
application?

Can someone give me a shove in the right direction?

Thanks

[Remy Blaettler]

Not sure about your design issue... struggling with these things myself :-S
But you could use the Caching Application Building Block from the Design &
Pattern team. Then you are on the save side.
http://msdn.microsoft.com/library/de...l/caching1.asp
--
Remy Blaettler
Helping you collaborate better!
www.collaboral.com
<mr********@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Hello everyone I'm hoping someone with more experience can suggest how
I would go about designing the following:

We have a standard web application and in its current form there are no
distinct layers. Everything is jumbled together. In an effort to
deploy new code in a more structured manner I've decided to break apart
the UI from the Business (no big stretch here). I have a data access
class in my business layer which is obviously called frequently.

We're using mulitple databases and thus have multiple connection
strings encoded in web.config. The data class I'm building now
retrieves the various connection strings and then depending on the use
a certain connection object is instantiated.

So far so good - no major issues here, however, rather than always
going to web.config (or AppSettings) and iterating through all the
AppSettings to find the connection strings seems silly so I chose to
iterate through them the first time the data class is called and then
store the list in cache which each subsequent instantiation calls.

My dimlema now is more one of design principle rather than a technical
problem. If my data class calls into the System.Web.Cache and I want
to get a current instance of the web application then in a sense I'm
starting to mix my layers again (aren't I).

Is it regarded as poor practice to 'touch' the HttpApplication object
from the business layer? It seems that the HttpApplication object
lives in the presentation layer and as such so does the cache. Am I
being too fussy about breaking apart my layers given that this is a web
application?

Can someone give me a shove in the right direction?

Thanks

[xhead]

I understand your discomfort.

I think you have a few options:
1. Use the Configuration Application Block from
www.microsoft.com/practices which implements its own caching mechanism
(either the older block or Enteprise Library).
2. Pass the web apps' Cache object into the methods that need it, or
into their New() constructors, and use it, and swallow your discomfort.
(I have done this, its not bad, you can substitute another cache object
when you need to use it with another platform at some point, should
that ever come).
3. Write your own connection string provider class that is a
Singleton-type class with its own caching mechanism - should be fairly
easy to do, and you can decide if you want to put a FileSystemWatcher
onto the configuration file or not (if its always in web.config, then
there's no point - any changes to that file and your app automatically
gets restarted).

Mike