Is having a global Config class a bad thing?

Question

Currently in my personal website I'm building I'm using a global static Config class to hold everything configurable I might need to change that is semi-global. So right now it looks about like this:

public static class Config
{
    public static string ConnectionString = "mongodb://localhost";
    //more configuration options..
    public static MongoDB.Driver.MongoDatabase GetDB(){
        MongoServer server = MongoServer.Create(Config.ConnectionString);
        MongoDatabase db = server.GetDatabase(Config.Database);
        return db;
    }
    public static Markdown GetMarkdown(){
        var options=new MarkdownOptions(){
            AutoHyperlink=true,
            AutoNewlines=false,
            EmptyElementSuffix=" />",
            LinkEmails=false,
            StrictBoldItalic=true
        };
        var m=new Markdown(options);
        return m;

    }
}

Is using a global config class like this an anti-pattern of some sort? Also, I prefer for my connection strings to be outside of web.config. I like my web.config to be as minimal as possible.

score 2 · Answer 1 · answered Mar 06 '11 at 03:27

2

Well of the 3 members only 1 is really config, the other two are utility really.

Having configuration in compiled code is really a pain to maintain if those configs need to be changed, since it requires a rebuild, that is really the reason for configuration files.

answered Mar 06 '11 at 03:27

Paul Creasey

28,321
10
54
90

Well, technically the GetMarkdown has some implicit configuration. – Earlz Mar 06 '11 at 03:37

score 2 · Answer 2 · answered Mar 06 '11 at 03:27

2

I do things similar to this but not for settings like connection strings. If the connection string needs to change, you need to update and rebuild your project. If you stored the connection string in your web.config, a simple update allow your app to immediately use the new setting (no recompile).

answered Mar 06 '11 at 03:27

Jonathan Wood

65,341
71
269
466

Well in my case, my website is small and quick to build and I rebuild it/upload it way more often than I change connections strings. Imagine other things though such as the Markdown configuration. – Earlz Mar 06 '11 at 03:32
It's a trade off. For me, I can't understand why you wouldn't want the connection string in web.config. I've found that to work very well. If, for whatever reason, that doesn't work for you and you understand the downside of hard coding it your source, it's your choice. – Jonathan Wood Mar 06 '11 at 03:34

score 1 · Answer 3 · answered Mar 06 '11 at 03:29

Earlz ,

Regarding your second question you can do something like this, there is no need to have all the connections or configs in web.config. You can have a separate config file and point that in the web.config file as below

<connectionStrings configSource="config\yourpath\connectionStrings.config"/>

Regarding the first question , write a common method which get the values. Load all the values to a constants file and write a helper class to get those values

Mike Valenty · Answer 4 · 2011-03-06T06:09:30.210

The anti-pattern is that you have GetMarkdown and ConnectionString together in the same class because they are both static, yet they really have no functional relationship. GetMarkdown and GetDB both look like factory methods and they should probably be in their own classes.

The Single Responsibility Principle says you should group things together that are likely change for the same reason. It's unlikely that your database connection and markdown config will change at the same time or for the same reason.

score 0 · Answer 5 · answered Mar 06 '11 at 05:41

We moved our config settings to the database. Makes it easier when moving from Dev to QA to Prod. The blog entry is here.

Related to this, we put the connection string off to the side in a WebEnvironment.config. So now we can promote our code with web.config changes and not worry about the connection string. That blog post is here.

Is having a global Config class a bad thing?

5 Answers5