Question

ASP.NET 3.5

Classes throughout our solution referenced ConfigurationManater.AppSettings[“”] to get appSettings (from web.config).

We decided we weren’t happy with that. Folks were mistyping appSetting key names in code (which compiled fine), and it was cumbersome to track usages. And then there’s the duplicated strings throughout the codebase as you reference the same appSettings all over the place.

So, we decided that only one class would be allowed to reference the ConfigurationManager, and the rest of the solution would reference that class when it needed the value of a certain appSetting. ConfigurationManater.AppSettings[“”] was static, so we exposed a bunch of static read-only properties off of our single Settings class.

public class Settings {
    public static string Foo {
        get {
            return ConfigurationManager.AppSettings["Foo"];
        }
    }
}

That worked pretty well, until we needed to mock the settings in our tests. We created an interface to enable our mocking (was this a mistake of any kind?).

public interface ISettings {
    string Foo {
        get;
        set;
    }

}

public class Settings : ISettings {
    public string Foo {
        get {
            return ConfigurationManager.AppSettings["Foo"];
        }
    }
}

And now we’re injecting the ISettings instance as a dependency of the objects which use settings values (the class/interface are in a project that everyone can reference without problems).

In places where we can’t inject an existing instance (e.g. Global.asax), we construct a new instance into a static field.

Given all of that, what would you recommend we change, and why?

Answer 1

Using an interface to represent configuration is a good idea. But your implementation looks a little off.

Joshua Flanagan wrote about writing application configuration code in a way that specific configuration sections can be injected into your code. This is a good idea, as it really decouples your code from worrying about details behind configuration. Have a read.

I think this will address the issue you are having re. testability.