A design consideration to access Web.Config
If you are going to access Web.config file for various configuration settings of yours e.g. ConnectionString.... Then sometimes it would be a good idea to develop a class specially to access configuration settings, something like a ConfigManager... what this class can inturn do is to access Web.Config file in its constructor to retrieve your configuration settings and fill up private variables and in turn expose them as properties...
The advantage of having this approach is that if you decide to change your source for these settings then you do not have to go to every page and change the way you access the settings you just change your class... Other than this there can be potential situations in which you might decide to encrypt some values in your web.config file later... This security enhancement would otherwise cause all your pages accessing this information change... During such situations it would be ideal to have a class like this...
To add icing to the cake you can make required member variables static so that the class's instance need not be created everytime... Also do try to make sure that every call to your property should not need to query web.config file to access values or else they may degrade performance...
PS: This is a design tip, it may not be perfect design for all situations these are just some of my generic thoughts, if you have anything to dispute please feel free to drop me an email
Binu from Trivendrum User Group has added the below thoughts...
There is one more advantage to this. if you want to deploy the application in different environments (developer sand box/ integration/ QA / production) it would be easy to have this App.Config . The possibility of using different encryption keys / SQL server in different environments is pretty high in real scenario and with the number of builds we deploy before pushing to production corroborates this.
-- Binu
No comments:
Post a Comment