I am probably breaking rules by posting this question here as its not strictly LLBL related (sorry frans), but I really am stuck on this one, and some of you guys may be able to help

Basically, my BL needs access to 2 things that are in the web.config file of the PL. One of these is my encrypted connection string. On application startup, I want to load, and decrypt the connection string, and store it in the cache for perf.

Heres the tricky bit: I want my BL classes to use the cache'd setting, so that they dont keep decrypting, but I don't know how to achieve this! My BL could get to the cache object I think via HttpContext, but thats my BL tied to the PL - I need to abstract that bot of functionality....should I create a "CacheManager" class that accesses the HttpContext instead and the BL uses this (so a new PL would also need a new CacheManager).....I can't help but think theres a pattern somewhere....

Of course, the other option is to just keep passing my decrypted conn string into my BL, but I'd rather not!

Please, put me out of my misery!!!

Since the connection string is global to the web application and does not change during the life of the application, stick the code in the Application_Start Event

protected void Application_Start(Object sender, EventArgs e)
{
     {... }
     Application["UnencryptedConnectionString"] = "whatever it is";
}

For a little abstraction, you can hide that it comes from the Application State

public class Site
{
     public static string GetUnencryptedConnectionString()
     {
           return (string)Application["UnencryptedConnectionString"];
     }
}

and use it in your BLL as such

[object].ConnectionString = Site.GetUnencryptedConnectionString();

If you have a lot of global settings to share across the web application, you would be better off to create a class and store the class in the application state as opposed to a bunch of objects. One or two is not a big deal, however. I used a method above, but if you prefer to create a propery, that is fine, too.

Hi Matt

I think you are looking for the singleton pattern.

Create an alone standing BL class that holds global BL settings like the connection string. - Then pass this class in as a param to the bl's class constructors or have it as a static class.

If your BL is only going to be used by the WepApp then leave the constring where it is.

if not then

store the connection string somewhere else...Can always create a config file for the BL.

I decided a few minutes ago to store my connection strings in the registry - encrypted. Because if you make a change to your webapp config file your Web App restarts and all session are lost - not nice!! So i read my connstring out from the reg per session. - I guess this ties me into windows.

Thanks for this!

I'll check out the singleton pattern, and consider where best to put my conn string!

wayne wrote:

Because if you make a change to your webapp config file your Web App restarts and all session are lost - not nice!!

You can configure an extrernal config file where you can make changes which you wouldn't want to cause an application restart, see here: http://www.devx.com/vb2themax/Tip/18880

Hi netclectic

Interesting...but it seems that you still need to restart the app... Read the highlighted line.

Am i reading this correctly?

quote from article

This means that if you frequently change the custom keys in the section, you'll cause frequent recompilation of the pages, and thus slow down the application. You can easily avoid this problem, at least for custom application settings, by storing the settings in an external file referenced from web.config. This option, undocumented but present also in ASP.NET 1.0, allows you to change your custom settings without editing the web.config file, and thus avoid the application restart. The drawback is that if you actually want to reload the settings, you have to manually force an application restart, for example by making a fake change to web.config.

wayne wrote:

Am i reading this correctly?

I read it as... if you are using an external file and actually do want a change in your external file to cause a reload the you have to manage that manually. If you just want to be able to read and use the new value in your app without causing a reload then this should be ok.

[edit] after knocking up a quick test app it seems your reading was indeed correct and this technique is not what you're looking for.

This means that if you frequently change the custom keys in the section, you'll cause frequent recompilation of the pages, and thus slow down the application. You can easily avoid this problem, at least for custom application settings, by storing the settings in an external file referenced from web.config

So if you don't want to your app to recompile when a setting in the config file changes you can use these external config files...but you wont know about the changes in the external file if you use the configreader unless your app restarts?....

I hope you don't mind me saying this...but his article seems kinda useless...unless you have your own reader to read the external config files...but then you don't need this file to be referenced in web.config.;/

Not sure how or where you would use this.

Luckily a connection string does not change that often. I think i will keep my connex in the reg for now.

Well, Thanks in any case.

wayne wrote:

I hope you don't mind me saying this...but his article seems kinda useless...unless you have your own reader to read the external config files...but then you don't need this file to be referenced in web.config.;/

My thoughts exactly after testing it.

Seems the only "use" it has is that it will let you change your config values without causing a reload leaving you to "force" a reload at some pre-determined time in the future.

Oh well, it sounded so promising on first read too.