The management of configuration in .NET applications was improved in .NET 2.0, now it is easier to have custom configuration sections, and we even have pre-built configuration section for Connection Strings (very useful for ADO.NET applications)
But... there are some design decisions I just don't get... "Configuration" is a separate concern from presentation (configuration can be used to set UI behavior, but in my opinion, configuration is in a lower layer), but now we have the WebConfigurationManager for web applications and the ConfigurationManager for client applications ...
From MSDN website:
Using WebConfigurationManager is the preferred way to work with configuration files related to Web applications. For client applications, use the ConfigurationManager class.
First, I thought... "this is going to be a problem", now I won't be able to read configuration in the lower layers (business facade, business rules, data access) without having to use my own proprietary "trick" to hide the fact that for those layers it is irrelevant whether the application has a WebUI or a WinUI... how could the .Net team make such a bad decision?
But then I realized... that i can use the ConfigurationManager from an WebUI (ASP.NET Application) without any problem... so my lower layers don't suffer from contamination from the presentation mechanism...
But now i am wondering... If the ConfigurationManager works perfectly... and doesn't tie my code to a particular presentation code... why should I use the WebConfigurationManager.... in fact... why should anyone use the WebConfigurationManager ? I just haven't figured out that...
No comments:
Post a Comment