Thoughts on how to refer to web.config key names in code

Question

When your web.config or app.config file has an appsettings entry, what is the best way to refer to its key in your code file?

Developers I have worked with have differing opinions on this. Some say to hard code the string and others suggest that there should be a file containing string constants and in your code, you use the constant as the appsettings key.

I would be interested in hearing other opinions on this. What do you do? Why is it the best?

Answer 1

String Constants for the win.

Keeping common strings in string constants makes things easier to maintain. If a key in your config file changes names, you only have to change it in one spot rather than worrying about finding every instance of the hard-coded string throughout your application.

Answer 2

String constants are better than nothing, but I'd initially vote for using a configuration class to provide strongly typed, intellisense friendly access to the config values. If I were stuck with using AppSettings for some reason.

In a more perfect world, I would vote for avoiding appSettings altogether and using custom configuration classes as they are much, much cleaner in the long run.

Answer 3

Skip the string constants, and create a configuration wrapper class instead.

class MyConfiguration
{
    public static string SomeConfigValue
    {
        get
        {
            return WebConfigurationManager.AppSettings["SomeConfigValue"];
        }
    }

    public static int SomeOtherConfigValue
    {
        get
        {
            return int.Parse(WebConfigurationManager.AppSettings["SomeOtherConfigValue"];
        }
    }

    //..and so on
}

Then you could get it like this:

string s = MyConfiguration.SomeConfigValue;
int i = MyConfiguration.SomeOtherConfigValue;

(You might consider not going the static route if you want to remove dependencies on the configuration system while unittesting)

Answer 4

I've always been a fan of Rick Strahl's method.

As for static strings being unwieldy, break your class down into subclasses and properties if you need to. For example in an application I'm currently working on, I have App.Settings for general settings, App.EmailSettings for email settings, and App.EventSettings for event logging settings.