拥有全局 Config 类是一件坏事吗？
目前，在我正在构建的个人网站中，我正在使用全局静态配置类来保存我可能需要更改的所有可配置内容，这是半全局的。所以现在它看起来像这样：
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 尽可能小。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
3 个成员中只有 1 个是真正的配置，另外两个是真正的实用程序。
如果需要更改这些配置，在编译代码中进行配置确实很难维护，因为它需要重建，这就是配置文件的真正原因。
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.
我做了与此类似的事情，但不是针对连接字符串之类的设置。如果连接字符串需要更改，您需要更新并重建项目。如果您将连接字符串存储在 web.config 中，则只需进行简单的更新即可让您的应用程序立即使用新设置（无需重新编译）。
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).
Earlz，
关于你的第二个问题，你可以这样做，不需要在 web.config 中拥有所有连接或配置。您可以有一个单独的配置文件，并在 web.config 文件中指出，如下所示
关于第一个问题，编写一个获取值的通用方法。将所有值加载到常量文件中并编写一个辅助类来获取这些值
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
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
反模式是，您将
GetMarkdown和ConnectionString放在同一个类中因为它们都是静态的，但它们实际上没有功能关系 。GetMarkdown和GetDB都看起来像工厂方法，它们可能应该位于自己的类中。单一职责原则表示，您应该将可能因相同原因而发生变化的事物分组在一起。您的数据库连接和 Markdown 配置不太可能同时或出于相同原因发生更改。
The anti-pattern is that you have
GetMarkdownandConnectionStringtogether in the same class because they are both static, yet they really have no functional relationship.GetMarkdownandGetDBboth 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.
我们将配置设置移至数据库。使从开发转向质量检查再转向生产变得更容易。 博客条目位于此处。< /a>
与此相关，我们将连接字符串放在 WebEnvironment.config 的一侧。所以现在我们可以通过 web.config 更改来提升我们的代码，而不必担心连接字符串。 该博客文章位于此处.
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.