Most of my programming has been in web-based applications, although I have done some desktop application development for personal projects. A recurring design issue has been on how to manage the configuration. For example, we all know that in ASP.NET the web.config is used frequently to hold configuration information, whether it be generated or manually configured.
Before I even knew what design patterns were, I would implement what would be in essence a Singleton pattern. I’d write a static class that, upon startup, would read the configuration file and store the information, along with any auto-generated information, in fields, which were then exposed to the rest of the application through some kind of accessor (properties, get() methods…).
Something in the back of my mind keeps telling me that this isn’t the best way to go about it. So, my question is, are there any design patterns or guidelines for designing a configuration system? When and how should the configuration system read the configuration, and how should it expose this information to the rest of the application? Should it be a Singleton? I’m not asking for recommended storage mechanisms (XML vs database vs text file…), although I am interested in an answer to that as well.
Not to sound like a cop out, but it’s really going to completely depend on your app. Very simple apps (sounds like your talking about Web based apps so I’ll skip fat clients), usually need nothing more than global config (you can use web.config and a singleton for that) and a per user config (a user table, and possibly a linked config table or name/value pair table can handle that.
More sophisticated apps might need a full hierarchy of configuration that’s protectable and overridable. For instance, I might have several app defined defaults, that can be overridden for each group that a user belongs to, the user themselves and finally an administrator defined value for a specific group or user that can’t be override by the user.
For that, I generally use a singleton “root config” object that has methods that expose additional levels of the hierarchy and config properties at each level. The root is responsible for resolving the heirarchy , but if necessary (for setting config for instance) you can traverse the heirarchy yourself to deal with settings specific to a single level in the heirarchy.
And finally, there’s the issue of latency. If you expect config settings to change often, reading them from storage each time they’re requested is best, but most expensive.
If not, you can cache settings, along with a “last read” date, and simply reread setting values into the cache after an expiry time.