UberUtils - Part 5 : Configuration
ÜberUtils Series posts so far :
- Part 1 : Cryptography - Hashing
- Part 2 : Cryptography (Continued) - Encryption
- Part 3 : Strings
- Part 4 : Collections
**** Please note that this code is using .NET 3.5 ****
Now onto the post - everyone I'm sure has used the system.configuration namespace before in a project. If you haven't then shame on you. If you have, then you know it should be used for storing things like :
- admin email address
- connection strings to a database
- log file path
- Tax amounts
and so on. I am a strong believer in NEVER hard code a setting. There is just no reason to do so. What happens if a setting changes down the line? Lets use a webmaster email as an example. You would have to locate wherever you use the email address (probably more than one place) and edit it. Then recompile and redeploy your changes. What a mission! Instead, just store it in the appsettings section of the .config file and edit the setting there whenever you need to.
I really do like using the appsettings and connectionstring sections in the .config files, but I think there is room for improvement. Wouldn't it be nice if appsettings was strongly typed for types other than string? Indeed it would. Here's an example: you store a "Testing" appsetting that determines if your website is in testing mode. If it is in testing mode, then you send all emails to Admin instead of sending emails to the actual users. Now every time you want to check if the site is in testing mode you have to convert the appsetting to a boolean first. Similarly with a Tax appsetting. You have to convert it to decimal every time before you can use it.
This then follows directly onto my next question : Wouldn't it be nice if appsettings and connectionstrings had default values? Yes again. Let's say the "testing" appsetting we spoke about earlier wasn't in the .config file. We would then want it to default to true. Maybe our tax appsetting should default to 0.14 and maybe we always use the same default connectionstring in our data access layer. Defaults would be great.
I address these two shortfalls with Utils.Configuration. Lets look at some examples:
bool bTesting = Utils.Configuration.ConfigurationManager.AppSettings["Testing", true];this gets the testing appsetting with a deafult of true (if we forgot to add the appsetting into the .config file). Notice too how it's strongly typed to be boolean. You could've also done it this way :
bool bTesting = Utils.Configuration.ConfigurationManager.AppSettings.GetValue("Testing", true);
This goes the same for the other types : Decimals, Ints, Doubles, Datetimes and obviously strings.
decimal nTax = Utils.Configuration.ConfigurationManager.AppSettings["Tax", 0.14M];The same applies for connectionstrings, except the output is obviously always a string. You can also check if a connection string exists so you can provide better error handling :
if (ConfigurationManager.ConnectionStrings.Exists("TestConn2"))download the assembly with unit tests here
{
return ConfigurationManager.ConnectionStrings["TestConn2", "Driver={SQL Server};Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;"];
}