Firstyll - Apologies! I'm posting a non-LLBL quuery in here But, the reason is that I respect you guys and your knowledge of .NET, so if anyone has a spare minute to answer my conundrum, I'm very gratefull!

Ok, I have a non-web app (its a console app), that makes constant calls to my BL. My BL methods all instantiate a DataAccessAdaptor, get something, and then return. This is fine, no probs. However, changes have come to light recently that mean that the app.config settings that are needed to connect to the database (connection string, catalog name, etc) are no longer stored in the current applications app.config, they are stored in a web.config file that is shared between a number of apps and the main web app. Heres a (crap) picture:

[Console App] -> [BLL Methods] <- [Web App]
...................................|                        
...................................|
...................................\/
..........[Read Central Config File]

I have this working... I have created a class that wraps the config file. This class loads the central web.config file as an XML document, and then finds the config setting it needs via a simple XPath query. It works, but I hate it! The performance must be awful, read on...

Say my app calls a BLL method 50 times. Each time the BLL method is called it needs to open a DataAccessAdaptor. So, to do this it first needs to get hold of the connection string. To do this, it calls the config wrapper class I just talked about. This class loads the config file, finds the setting, and uses it. All this happens 50 times! Thats 50 XMLDocuments being loaded, and 50 XPath queries being fired....thats nasty!

I guess what I need to do is cache the connection string (and other values) somehow from the config file, but how and where can I do this? What I don't want to do is have to pass in to my BL methods a connection string to use, thats pretty nasty too.

If it was an ASP.NET only system, I would add the connection string to the cache object, and whenever it was requested in future I could check if it was there or not first.... But its a console app....

Again sorry for posting a non-llblgen topic here...

Read the values once from the config file and store the values in static variables - then when coming in the 2nd time see if those variables are set - it they are don't read from the config.

You can also create a singleton class that get created onces - reads the values once.

Thanks Wayne.

But... where would this class live? If I had 2 BLL classes, BLLA and BLLB, and BLLA.Dosomething is called, it can save the value in a static class. But the scope of the class is limited to BLLA, isn't it? So, when BLLB.DoSomething is called, it will not find the static values anywhere, and load them up again.....or am I wrong there?

You can read them from the config file every time, .NET caches the config file in memory and converts it into an object IMHO, as access to config variables after the first time is very fast (< 10ms)

Fair point Frans, but my partiucular situation is weird, because I have a console app loading the config file from another location. So...I can't depend on just calling Configuration.AppSettings - I have a method that loads the config file from a set location, and uses XPath to find the matching element... so I get no caching

What would be cool would be if I could make the console app use the config file from somewhere else as though it were its own......hmmmmm....

Hi Matt

a singleton class does not live anywhere except for inside its own type - nobody needs to explicitly create it and anybody can access it from anywhere that is the power of this pattern. It is design pattern but it its power is not implemented via the architecture but via the way it is coded.

The object gets accesed via static methods that are bound to the type and not to a instantiated object. Only a limited instances of the object type can ever exist inside a assembly that is using it. - The amount get's controlled programmatically. If you want to share the class over different applications that are sharing a common library - you will have to look at creating a mutex.

Here is a simple example:

    public sealed class ConnectionConfig
    {
        private static ConnectionConfig instance=null;

        public string DBConnection;

            ConnectionConfig()
            {
                //This is where you would read from the config file.
                DBConnection = "TestConnection";
            }

        public static ConnectionConfig GetConnectionConfig()
        {
            if (instance==null)
                instance = new ConnectionConfig();
            return instance;
        }
    }
}

Don't know if this might help you, it's something i bookmarked a while ago thinking.... "that could come in handy"

http://weblogs.asp.net/pwilson/archive/2003/04/09/5261.aspx

Thanks Wayne - a singleton can seriously help me! My only minor niggle with that is that a singleton can only work within the context of the process it lives in (the BLL). so when the app is done with the BL, the singleton is lost, and when I instantiate a new BL class somewhere else, the BL will instantiate a new singleton.. Still, thats a minor ocerhead to what I was donig, so I think its the way to go.

netclectic: Interesting artcile, could def. be an alternative way for us to go !! Thanks!

The microsoft configuration management application block allows you to define an external XML file that has configuration info in it.

So you could make your applications use the MS CMAB to load the external file that contained all of the xml for all of the applications. The console app could have a section handler that points to the external xml file and the other applications could have this as well. I beleive the CMAB can use a UNC to get at the file.

The other really cool thing is that the CMAB will also cache the values and monitor the values for changes and recache the values on change.

Thanks my story and im sticking to it

MattWoberts wrote:

so when the app is done with the BL, the singleton is lost, and when I instantiate a new BL class somewhere else, the BL will instantiate a new singleton..

It is possible to cache it some more - but i don't think that it will have any better performance than reading the config file from scratch.

I agree. Use the CMAB