Is using a static class to facilitate access to appsettings acceptable? [closed]

Answer 1

Here's an example of testable code that addresses the commenters' concerns:

interface IEmailSettings {
    string Server { get; }
    string Sender { get; }
    string[] Recipients { get; }
}

If you store your settings in the app.config, use this:

class AppConfigEmailSettings : IEmailSettings {
    public AppConfigEmailSettings() {
        this.Server = ConfigurationManager.AppSettings["server"];
        this.Sender = ConfigurationManager.AppSettings["sender"];
        this.Recipients = ConfigurationManager.AppSettings["recipients"].Split(';');
    }

    public string Server { get; private set; }
    public string Sender { get; private set; }
    public string[] Recipients { get; private set; }
}

If you store your settings in the database, use this:

class DatabaseEmailSettings : IEmailSettings {
    public DatabaseEmailSettings(string connectionString) {
        //code to connect to database and retrieve settings
    }
    //you can use the same fields and properties from AppConfigEmailSettings
}

For testing, you can use something like this:

class MockSettings : IEmailSettings {
    public string Server { get { return "localhost"; } }
    public string Sender { get { return "sender@example.com" } }
    public string[] Recipients { get { return new string[] { "r1@example.com" }; } }
}

You get the idea. This code is easier to test than yours. Also, if you inject IEmailSettings into the code that sends emails, you can easily change how you store your email settings by changing one line of code in your whole application. That's the line that instantiates the IEmailSettings object to AppConfigEmailSettings or DatabaseEmailSettings or something else.