Web 应用程序配置设置 - 最佳实践
我最近参与了一个 Web 应用程序项目的修补，并注意到以前的开发人员使用数据库表进行配置设置，而不是 web.config (app.settings)。
我应该使用哪个？ web.config 还是数据库表？哪个最好？
I was recently involved with patching a web app project and noticed the previous developer used database table for configuration settings instead of web.config (app.settings).
Which should I use? web.config or database table? Which is best?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在以下情况下，这些内容应该进入 web.config：
它们必须可用才能使数据库可用（数据库连接字符串！）
如果它们发生更改，您希望应用程序池刷新，或者极不可能更改它们。
这些东西应该按以下方式进入数据库情况：
您的数据库和 Web 层都使用该配置。
您需要能够动态更改配置，而不强制刷新应用程序池。
也就是说，如果您要将配置放入数据库中，您可能希望以某种方式将其缓存在 Web 层中，这样就不会不必要地访问数据库。我建议为此使用 Cache 类。
除了上述所有内容之外，您还需要考虑公司使用服务器的政策。如果您使用数据库非常非常困难，那么将内容放入 web.config 中可能更有意义，反之亦然。
Things should go into the web.config in the following situations:
They're things that must be available to make the database available (db connection string!)
They're things that, if they should change, you want the application pool to refresh, or that are insanely unlikely to change.
They're things that need to be available when the database is unavailable for any reason (such as a list of email addresses and an smtp server to send error messages to, or locations where log files belong)
Things should go into the database in the following situations:
Both your DB and your web layer use that configuration.
You need the ability to change the configuration on the fly, without forcing an application pool refresh.
That said - if you're going to put your config in the database you probably want to cache it in some way in the web layer so you're not hitting the db unnecessarily. I suggest the Cache class for this.
In addition to all of the above, you will also need to consider your company's policy for working with your servers. If its very, very hard for you to work with the db, it might make more sense to put things in the web.config and vice versa.
使用数据库进行设置的优点之一是可以在不中断生产网站的情况下即时更改内容。
对 web.config 文件的更改将导致 IIS 上的工作进程回收并重新启动应用程序。如果您使用 InProcess 会话，这些会话将会丢失。这可能会扰乱您网站的用户。
One advantage for using a database for the settings is that things can be changed on the fly without disrupting the production website.
Changes to the web.config file will cause the worker processes on IIS to recycle and the app to be re-started. If you are using InProcess sessions, those will be lost. This could potentially disrupt your website users.
我们结合使用 web.config 设置和数据库级别设置。
对于每个设置，我们都会问以下问题：“此设置是否特定于应用程序运行所在的计算机？”如果是，那么它就会进入 web.config。如果没有，那么我们会问一个额外的问题：“如果更改此设置，是否应该强制重新启动应用程序？”如果是，则 web.config。对于我们的服务级别协议来说，重启通常是不可接受的。
我们的大多数应用程序都是多租户的和/或在网络场中运行。 web.config 中包含一些简单的内容，例如本地文件系统路径、日志记录级别或数据库连接字符串。原因是这些处理特定于该机器的资源。
几乎所有其他内容都会影响程序执行，并且必须可供应用程序层和数据层访问。此外，其他应用程序往往需要它们（假设多个应用程序访问同一个数据库）。
We use a combination of both web.config settings and database level settings.
For each setting we ask the following question: "Is this setting specific to the machine that the application is running in?" If it is, then it goes in the web.config. If not, then we ask an additional question: "If this setting is changed, should the app be forced to reboot?" If yes, web.config. More often than not a reboot is not acceptable for our service level agreements.
Most of our applications are multi-tenant and/or run in a web farm. Simple things like a local file system path, logging level, or database connection strings go in the web.config. The reason is that these deal with resources specific to that machine.
Pretty much everything else is going to impact program execution and must be accessible to both the app and data layers. Also, they tend to be needed by other applications (assuming multiple applications hit the same database).
这是有道理的。 dev使用DB进行设置，就用它吧。你必须有一个 web.config，我认为没有它 ASP.NET 就无法工作。项目配置设置应进入 web.config（自定义控件、附加程序集等的声明），但用户设置或任何特定于业务逻辑的内容可能最好放在数据库中。
It it makes sense why the prev. dev used the DB for setting, go with it. You must have a web.config, I think an ASP.NET can't work without it. Project configuration setting should go into web.config (declarations of custom controls, additional assemblies etc...), but user settings or anything specific about the business logic may be better off in the database.
我公司的开发人员和 DBA 之间存在争议的问题。
在我看来，您应该始终使用配置文件进行应用程序级别的只读设置。如果设置是用户特定的或在运行时可编辑的，您可能想也可能不想重新考虑该方法。
我见过这样的情况：设置存储在数据库中，并在存储过程内部使用。我可以看到这样做的一些理由，但这并不重要，因为该值可以通过参数传递给过程。
A contentious issue between developers and DBAs at my company.
In my opinion you should always use configuration files for application level, read-only settings. If the settings are user specific or editable at runtime you may or may not want to reconsider the approach.
I have seen situations where settings are stored in the database that are used internally within stored procedures. I can see some justification for this, but it’s not critical since the value can be passed to the procedures via a parameter.
一个考虑因素可能是，一旦部署了 Web 应用程序，开发人员就无法再访问生产环境中的
web.config文件。如果他偶尔需要查看设置以提供任何形式的支持，那么将设置放入数据库中，以便他可以对配置表进行只读访问可能会很有意义。
One consideration may be that once the web application is deployed, the developer no longer had access to the
web.configfiles in the production environment.If he's occasionally needing to view settings to provide any form of support, putting settings in a database where he can get read-only access to a configuration table may make tons of sense.
支持数据库的一个用例是负载平衡应用程序，例如网络场。可能有一些设置与单个计算机相关，与场中的其他计算机不同，需要进入 web.config，但可能会有大量设置在整个场中应该是相同的。该场应该从外部看起来像一个单一的应用程序，如果它可以像一台机器一样配置，那么它就会受益。这意味着某种共享存储库，例如数据库。
One use case that argues for a database is load-balanced applications, like web farms. There may be some settings that are relevant to a single machine distinct from the other machines in the farm, that need to go in the web.config, but there will probably be a whole slew of settings that are supposed to be identical across the farm. The farm is supposed to look like a single application from the outside, and can benefit if it can be configured like a single machine. That means some sort of shared repository, like a database.