Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Building a Better Configuration Settings Class : Page 2

.NET provides a basic configuration management class, but it's not as flexible or easy to use as it could be. Find out how you can create a more flexible interface that provides strong typing, encryption, and write access to your application settings.


advertisement
Improving Settings with Class
The base functionality in .NET is a big improvement over no configuration features at all, but it leaves a lot to be desired in usability terms. Luckily, you can very easily extend the functionality and provide a better interface, building on top of the existing functionality. The wwAppConfiguration class works in conjunction with the .NET ConfigurationSettings class and provides the following improvements:

  • A typed interface to configuration settings
  • Default values returned if a key is not set
  • Default value automatically written into the .config file
  • Read and Write access to keys
  • Error handling for invalid entries
  • Encryption for specific keys
  • Ability to use non .config files for storage
How It Works
The main goal of the ConfigurationSettings class is to provide a standard, strongly typed class interface to configuration settings. The reasoning behind this is clear: strong typing catches any type of naming errors at compile time so there are no runtime surprises. Further, you can use IntelliSense to access the settings, so you don't have to jump to your config file to remember what the key names are (if they're there).

Static constructors fire exactly once for a given class, when a static field is accessed on the class.
To provide this functionality, you create a new subclass of the wwAppConfiguration class and add the fields or properties that become your configuration settings. The class takes these properties and persists them into the configuration file, reading and writing the data as needed, shuttling data between the configuration file and the class.

The wwAppConfiguration class relies heavily on inheritance. There's an abstract class (wwAppConfiguration) that provides the worker interface. This abstract class provides the logic to read and write configuration settings into the public members of the class.

Your subclass only adds the public properties or fields that make up the configuration settings. Reading of the data happens automatically when you instantiate the class. To avoid having to reload this data each time you need it, it's best to store the object to a globally accessible static property of some sort. There will be more about this later.

To implement a class with the settings in the Web.config file shown earlier, use the code shown in Listing 1.

That's all it takes! Now you can simply instantiate your class and start reading properties to get configuration information stored in the .config file:

WebStoreConfig Config = new WebStoreConfig(); string ConnectionString = Config.ConnectionString; decimal TaxRate = Config.TaxRate; bool ProcessCards = Config.ccProcessCardsOnline; ServerTypes ConnectType = Config.ConnectType;

Note that you get fully typed values back from the value stored in the configuration, if any. Property values are converted to the proper type automatically. There is no manual parse code. Even enum values are converted. If a single value doesn't exist in the .config file (because you added a property, perhaps), the default value you assigned to the field in the class definition is returned and the key is written into the .config file. If a value is invalid and the type cannot be converted, the default is returned as well.

If you run this code for the first time and did not create the AppSettings section in the .config file, the section is automatically created and all the entries from this class are added automatically. This is nice, as you know if you've ever debugged a large number of entries and accidentally mistyped one of the keys and were wondering why a value wasn't reading properly. Here, the keys are always automatically created for you so there's no chance of mistyping anything. This makes it much easier to deploy your application for the first time as you don't have to remember to fill the AppSettings section in your installation: the defaults get there automatically the first time the Configuration class is accessed.

Note that if you're using ASP.NET, writing to the Web.config file requires that you give write access rights to the ASPNET/NETWORK SERVICE account. If writing is not enabled, the default values are not written and you have to manually enter the keys or use a link that allows impersonation to save and update settings. There's more info on this topic in my WebLog.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date