Configuration settings in (web.config|app.config) versus a Static Class Object

Question

I am just looking at the BlogEngine.Net source code and was intrigued at how it stores application settings.

Instead of using web.config or app.config which I am accustomed to, the source uses a static class object implemented using a singleton pattern to achieve the application settings. the information is still stored in a settings file but any calls to retrieve information is done via the class object which preloaded all information into property values.

Any advantages of different approaches?

Answer 1

If you have an admin area where you can alter the configuration settings, writing to web.config will cause the app to be restarted and all users to lose their session data. Using a separate config file will prevent this from happening.

Answer 2

One serious drawback to this model is the inability to pick up changes made outside the application. As the config settings are loaded at startup and maintained in memory all changes have to be done either through the administration pages or while the application is offline.

Answer 3

There are pros and cons to having properties that act as config settings accessors.

On one hand, having such a class with properties provides the development team with better organized and more reusable code.

On the other hand, every time you add a new config setting, are you going to have to update the class and rebuild the application?

Answer 4

From my understanding, the web.config files are loaded into cache upon application start. I haven't looked this up in a very long time so I could be mistaken. If it's true, then I don't really see why a singleton, static class pattern would be beneficial. If the ASP.Net State service or a SQL State Server is used instead of the default in-process session management, restarting of the web app (via IIS or by modifying the config) won't impact sessions. All in all, I'm not entirely certain why blogengine.net would go that route.