Question

目前在我的个人网站上我正在构建我正在使用全局静态配置类来保存可能需要更改的所有可能是半全局的。所以现在它看起来像这样：

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;

    }
}

使用像这样的全局配置类是某种反模式吗？另外，我更喜欢我的连接字符串在web.config之外。我喜欢我的web.config尽可能小。

Answer 1

3个成员中只有1个是真正的配置，其他两个实际上是实用的。

如果需要更改这些配置，那么在编译代码中进行配置真的很难维护，因为它需要重建，这才是配置文件的真正原因。

Answer 2

我做的事与此类似，但不适用于连接字符串等设置。如果需要更改连接字符串，则需要更新并重建项目。如果您将连接字符串存储在web.config中，则只需一个简单的更新即可让您的应用立即使用新设置（无需重新编译）。

Answer 3

Earlz，

关于你的第二个问题，你可以做这样的事情，没有必要在web.config中拥有所有的连接或配置。您可以拥有一个单独的配置文件，并将其指向web.config文件，如下所示

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

关于第一个问题，写一个获取值的常用方法。将所有值加载到常量文件并编写辅助类以获取这些值

Answer 4

反模式是您在同一个类中同时拥有GetMarkdown和ConnectionString，因为它们都是静态的，但它们实际上没有功能关系。 GetMarkdown和GetDB 看起来像工厂方法，它们可能应该在他们自己的类中。

Single Responsibility Principle表示你应该将可能因同样原因而改变的事物分组在一起。您的数据库连接和降价配置不太可能同时或出于同样的原因发生变化。

Answer 5

我们将配置设置移至数据库。从Dev转到QA再到Prod时更容易。 The blog entry is here.

与此相关，我们将连接字符串放在WebEnvironment.config中。所以现在我们可以通过web.config更改来推广我们的代码，而不用担心连接字符串。 That blog post is here.

拥有全局Config类是件坏事吗？

5 个答案: