Web 应用配置设置 - 最佳实践答案

【问题标题】：Web App Configuration Settings - Best PracticesWeb 应用配置设置 - 最佳实践
【发布时间】：2023-04-06 16:46:01
【问题描述】：

我最近参与了一个 web 应用项目的修补工作，并注意到以前的开发人员使用数据库表进行配置设置，而不是 web.config (app.settings)。

我应该使用哪个？ web.config 或数据库表？哪个最好？

【问题讨论】：

感谢附加标签，谢谢安迪 :)

【解决方案1】：

支持数据库的一个用例是负载平衡的应用程序，例如网络农场。可能有一些与场中与其他机器不同的单台机器相关的设置需要进入 web.config，但可能会有一大堆设置在整个场中应该是相同的.从外部看，农场应该看起来像一个单一的应用程序，如果它可以像一台机器一样配置，它就会受益。这意味着某种共享存储库，例如数据库。

【讨论】：

【解决方案2】：

以下情况应该进入web.config：

它们是使数据库可用时必须可用的东西（数据库连接字符串！）
如果它们应该更改，您希望应用程序池刷新，或者极不可能更改。
当数据库因任何原因（例如电子邮件地址列表和发送错误消息的 smtp 服务器或日志文件所属的位置）不可用时，它们是需要可用的东西

以下情况应该进入数据库：

您的数据库和 Web 层都使用该配置。
您需要能够即时更改配置，而无需强制刷新应用程序池。

也就是说 - 如果您要将配置放入数据库中，您可能希望以某种方式将其缓存在 Web 层中，这样您就不会不必要地访问数据库。我建议为此使用 Cache 类。

除了以上所有内容外，您还需要考虑贵公司关于使用服务器的政策。如果使用 db 对您来说非常非常困难，那么将内容放在 web.config 中可能更有意义，反之亦然。

【讨论】：

以下是什么意思？ 您的数据库和 Web 层都使用该配置。

【解决方案3】：

我们结合使用 web.config 设置和数据库级别设置。

对于每个设置，我们都会提出以下问题：“此设置是否特定于运行应用程序的机器？”如果是，那么它将进入 web.config。如果不是，那么我们会问一个额外的问题：“如果更改了此设置，是否应该强制重新启动应用程序？”如果是，web.config。我们的服务级别协议通常不接受重新启动。

我们的大多数应用程序都是多租户的和/或在网络场中运行。 web.config 中包含本地文件系统路径、日志记录级别或数据库连接字符串等简单内容。原因是这些处理特定于该机器的资源。

几乎所有其他内容都会影响程序执行，并且应用层和数据层都必须能够访问。此外，其他应用程序往往也需要它们（假设多个应用程序访问同一个数据库）。

【讨论】：

【解决方案4】：

使用数据库进行设置的一个优点是可以在不中断生产网站的情况下即时更改内容。

对 web.config 文件的更改将导致 IIS 上的工作进程回收并重新启动应用程序。如果您使用 InProcess 会话，这些会话将丢失。这可能会扰乱您的网站用户。

【讨论】：

【解决方案5】：

一个考虑因素可能是，一旦部署了 Web 应用程序，开发人员就无法再访问生产环境中的 web.config 文件。

如果他偶尔需要查看设置以提供任何形式的支持，那么将设置放入数据库中，他可以在其中获得对配置表的只读访问权限。

【讨论】：

【解决方案6】：

我公司的开发人员和 DBA 之间存在争议的问题。

在我看来，您应该始终将配置文件用于应用程序级别的只读设置。如果设置是用户特定的或在运行时可编辑的，您可能需要也可能不想重新考虑该方法。

我见过一些设置存储在数据库中的情况，这些设置在存储过程内部使用。我可以看到一些理由，但这并不重要，因为可以通过参数将值传递给过程。

【讨论】：

关于存储过程的要点。我认为在数据库中进行配置使数据库访问变得更加容易。然而，这个 prev dev 使用了用户和应用程序的所有设置。

【解决方案7】：

为什么上一个是有道理的。开发人员使用数据库进行设置，随它去吧。您必须有一个 web.config，我认为 ASP.NET 没有它就无法工作。项目配置设置应该进入 web.config（自定义控件的声明、附加程序集等......），但用户设置或任何特定于业务逻辑的内容可能在数据库中更好。

【讨论】：

不，我知道 web.config 是必需的，但我不确定这是应用程序设置部分。基本上，我的印象是应用程序设置是有意义的——在数据库配置更改有点混乱的情况下，可以快速轻松地进行更改。你不改变以前的开发工作是对的，如果它没有坏就不要改变它。