All of the ASP.NET web projects that I've ever worked on relied on some appSetting within the web.config file. When ever the variable was needed, some code was used to grab the variable in question than modify the type as needed or used simple string comparisons. The problem I found early on working on a small team was that every member had their own twist on grabbing and using the data from within the web.config file. While no method was wrong, the differences in using the same variable degraded their integrity.
My solution was to encapsulate the appSettings in a static class that returned the variables as properties of the correct type. This encapsulation also isolated the place where all appSettings were obtained making changes much easier while, at the same time, normalizing their usage. It takes a few minutes longer of up front work when adding new settings but the ease of usage diminishes that ten-fold.
Another plus is that a missing setting won't throw an error since we check for it's existence before we actually try and cast the value. In my experience, not all developers check first, they assume it'll be there -bad idea.
Note: The below example is utilizing .NET 2.0 but the same results can be obtained using 1.1 by simply changing
ConfigurationManager.AppSettings[""] to
ConfigurationSettings.AppSettings[""].
First off, here are a few differnet appSettings that have varying usages and types:
<add key="PromoExpiration" value="11/1/2006"/>
<add key="IntroText" value="This is some random text ..."/>
<add key="DisplayExtra" value="true"/>
<add key="LoopCount" value="16"/>
Next I created a class called ConfigController where the getters for the above settings are obtained. Here are two examples; the first demonstrates a bool while the second shows an int data type:
public static bool DisplayExtra
{
get
{
if(ConfigurationManager.AppSettings["DisplayExtra"] != null)
{
return bool.Parse(ConfigurationManager.AppSettings["DisplayExtra"]);
}
else
{
return false;
}
}
}
public static int LoopCount
{
get
{
if(ConfigurationManager.AppSettings["LoopCount"] != null)
{
return int.Parse(ConfigurationManager.AppSettings["LoopCount"]);
}
else
{
return -1;
}
}
}
To further ensure that no errors are thrown, a
try catch block can be used when casting the data. In my opinion it's overkill but when you work on a project where the client can and does edit the web.config file outside of your control, exception handling might be in order.
if(ConfigurationManager.AppSettings["PromoExpiration"] != null)
{
try
{
return DateTime.Parse(ConfigurationManager.AppSettings["PromoExpiration"]);
}
catch(Exception)
{
return DateTime.MinValue;
}
}
else
{
return DateTime.MinValue;
}
Once the controller is in place, it's usage is as simple as:
PromoPanel.Visible = (DateTime.Now < ConfigController.PromoExpiration);
IntroLabel.Text = ConfigController.IntroText;
ExtraPanel.Visible = ConfigController.DisplayExtra;
for(int i = 0; i < ConfigController.LoopCount; i++)
{
Literal l = new Literal();
l.Text = String.Format("Count: {0}<br />", i);
LoopPlaceHolder.Controls.Add(l);
}
In summary, keep access to the web.config settings in one place and return the resulting values using their respective types to ensure proper usage throughout your solution.
Download the solution:
ConfigControllerWebSiteExample.zip (5.3 KB)