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;"];
}