在 ASP.NET 应用程序中存储应用程序配置参数的正确方法是什么?

发布于 2024-10-09 15:25:30 字数 346 浏览 0 评论 0原文

我们在 C# .NET 4 ASP 网站中的每个模块都有很多应用程序参数。

参数示例:超时、公式常量、每个模块的线程限制、每次使用的费用等。

我们知道以下方法中最好的是什么:

  1. 使用数据库配置表
  2. 使用 xml。在启动时(以及在 xml 更改时)将该 xml 加载到本地缓存中,
  3. 使用 public const int XYZ = 123 的简单 Constants.cs 文件;键值对的类型。
  4. web.config(虽然我认为它主要用于配置的部署类型)
  5. 还有其他方式吗?

关于利弊和标准的帮助。遵循的方法会有所帮助。

We have lot of application parameters for each module in a C# .NET 4 ASP website.

parameter examples: timeouts, formulae constants, thread limits per module, $ charges per usage etc.

What is best out of following approaches we know:

  1. Use DB config table
  2. Use an xml. load that xml into local cache on start (and on xml change)
  3. simple constants.cs file with public const int XYZ = 123; type of key-value pairs.
  4. web.config (though i think its mostly for deployment type of config)
  5. Any other way ?

Help on pros and cons and std. approach followed would be helpful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

青丝拂面 2024-10-16 15:25:31

那么,选项 4 (web.config) 比选项 2 (xml) 更安全。 .config 不能那么容易下载。

对于其余的,这取决于一点,没有“正确”的方法,但我会使用 web.config ,除非有一个很好的理由不这样做。 Web.config 不仅仅用于“部署相关”的内容。

Well, option 4 (web.config) is safer than option 2 (xml). A .config can't be downloaded so easily.

For the rest it depends a little, there is no 'right' way but i would use a web.config unless there is a really good reason not to. Web.config is not just for 'deployment related' stuff.

ゞ记忆︶ㄣ 2024-10-16 15:25:31

1.- 当您想要更改参数而无需重新启动应用程序时,请使用数据库配置表。更喜欢它的用法。

2.- 使用xml 文件。如果您的应用程序是面向 XML 的。

3.- 简单的常量文件。这不应该有参数,常量不是参数。

4.- web.config。使用 appSettings 项来存储不会连续更改的简单值(DBConnectionTimeout、DBCommandTimeout、PageSize 等。),使用自定义的 sectionGroup 来存储更复杂的值参数。

这是一个简单的配置表定义

CREATE TABLE ctr_group_parameters (
    option      varchar(50)  NOT NULL,
    id_group     int          NOT NULL,
    description varchar(100) NOT NULL,
    value       varchar(200) NOT NULL,
    PRIMARY KEY CLUSTERED (option, id_group) )

1.- Use DB config table when you want to change parameters without having to restart your application. Prefer its usage.

2.- Use xml file. If your application is XML oriented.

3.- Simple constants file. This should not have parameters, constants are not parameters.

4.- web.config. Use appSettings items for storing simple values that does not change continuously (DBConnectionTimeout, DBCommandTimeout, PageSize etc..), use customized sectionGroup for more complex parameters.

Here is a simple configuration table definition:

CREATE TABLE ctr_group_parameters (
    option      varchar(50)  NOT NULL,
    id_group     int          NOT NULL,
    description varchar(100) NOT NULL,
    value       varchar(200) NOT NULL,
    PRIMARY KEY CLUSTERED (option, id_group) )
兔姬 2024-10-16 15:25:31

如果这些设置不会经常更新,我喜欢使用 web.config。如果它们更新得更频繁一些,我会考虑使用数据库表。

If these are settings that wouldn't be updated often, I like using web.config. If they are updated a bit more often, I'd think about using a database table.

并安 2024-10-16 15:25:31

我会将 web.config 用于您知道永远不会更改的内容,除非它随应用程序逻辑一起更改。对于可能需要独立于代码进行更改的内容(例如 $ 费用),您可能需要使用数据库。

I'd use the web.config for stuff you know never changes except when it changes along with application logic. For stuff that may need to change independently of code (like $ charges) you may want to use a database.

身边 2024-10-16 15:25:30

我喜欢#1,将值存储在数据库中,原因如下:

  1. 这适用于网络场。您不必在多个服务器上同步 web.config 的版本。
  2. 进行更改不需要重新编译和重新部署应用程序。改变可以是立竿见影的。
  3. 为授权用户创建一个维护网页来更新值而不妨碍生产支持相对容易。
  4. 任何有权访问数据库(或显示这些值的维护页面)的人都可以在应用程序外部随时确定这些值。没有人需要通读源代码或查看 web.config 文件。
  5. 无需重新启动网络应用程序即可使更改生效。

编辑:关于其他提议方法的附加评论:
如果应用程序将位于网络场上,则所有三种非数据库选择都需要部署到所有服务器。如果涉及大量 Web 服务器,如果部署过程很复杂,或者如果公司政策严格限制谁(以及何时)可以将更改部署到生产服务器,那么这不是一件小事。

即使没有网络场,在企业生产环境中,部署更改也可能极其缓慢。

关于常量,我发现它们往往散布在应用程序代码中。找到他们可能是一个真正的挑战。当然,如果你有集中配置常量的纪律,就不会有这个问题。

还有另一种方法不在您的列表中,即使用资源文件 (.resx)。虽然这通常用于本地化,但我也看到它用于配置值,特别是用于存储标准消息的文本。虽然您不必重新编译应用程序来更改 .resx 文件,但更改它会导致应用程序重新启动。

总而言之,我更喜欢数据库方法的原因是部署的速度和简便性、避免重新编译和应用程序重新启动、将数据集中在应用程序外部以及使业务用户可以访问数据。

I like #1, storing the values in the database, for several reasons:

  1. This works on a web farm. You don't have to synchronize versions of web.config on multiple servers.
  2. Making changes does not require recompiling and redeploying the application. Changes can be immediate.
  3. It is relatively easy to create a maintenance web page for authorized users to update the values without bugging production support.
  4. The values can be determined at any time from outside the application by anybody given access to the database (or to a maintenance page displaying the values). Nobody has to read through the source code or look at web.config files.
  5. The web application does not have to be restarted for the change to take effect.

Edit: Additional comments about the other proposed methods:
If the app is going to be on a web farm, all three non-database choices will require deployment to all servers. This is not a trivial matter if a lot of web servers are involved, if the deployment procedure is complicated, or if corporate policy severely limits who (and when) changes can be deployed to production servers.

Even when there is no web farm, in a corporate production environment, it can be excruciatingly slow to deploy a change.

Regarding constants, I have found that they tend to get sprinkled all over the application code. Finding them can be a real challenge. Of course, if you have the discipline to centralize the configuration constants, you won't have this problem.

There is one other approach not on your list, which is using resource files (.resx). While this is generally used for localization, I have seen it used for configuration values, and especially for storing the text of standard messages. While you don't have to recompile your application to alter a .resx file, changing it will cause the application to restart.

In summary, then, my reasons for preferring the database approach are the speed and ease of deployment, avoiding recompilations and app restarts, centralizing the data outside the application, and making the data accessible to business users.

攀登最高峰 2024-10-16 15:25:30

您似乎将不同级别的设置混合在一起:

  • Timeout 最适合成为 web.config 文件的一部分,而
  • $ 每次使用费用 与每次使用更相关用户设置并应与用户一起位于数据库中。

如果您决定使用 web.config 文件,我建议您执行以下操作,以使您的 web.config 文件远离应用程序设置。

创建一个文件来存储您的设置。我通常创建一个名为应用程序的文件,例如 nerddinner.config。请记住,config 扩展是出于安全原因而使用的。

在文件中添加您的设置:

<appSettings>
  <add key="Test" value="Hello world"/>
</appSettings>

web.config 文件中,创建 ,但将其重定向到其他文件:

<configuration>
  ...
  <appSettings configSource="nerddinner.config" />
  ...
</configuration>

You seem to mix different level of setting together:

  • Timeout is best suited to be part of a web.config file, while
  • $ charges per usage is more related to a per-user setting and should be located in a database along with the user.

Should you decide to use a web.config file, I suggest the following to keep your web.config file clear of application settings.

Create a file that will store your settings. I usually create a file named as the application, like nerddinner.config. Remember that the config extension is used for security reason.

Add your setting in the file:

<appSettings>
  <add key="Test" value="Hello world"/>
</appSettings>

In your web.config file, create the <appSetting>, but redirect it to the other file:

<configuration>
  ...
  <appSettings configSource="nerddinner.config" />
  ...
</configuration>
决绝 2024-10-16 15:25:30

按优先顺序排列:

  1. Web.config - 使用 web.config 的主要好处是,当文件更改时,应用程序池会自动回收。此外,您还可以使用众所周知的 System.Configuration API 来访问数据。当 ASP.NET 已经支持配置文件时,您不必浪费时间使用单独的 XML 文件并监视它的更改。

  2. 常量文件 - 它具有与 web.config 相同的应用程序池回收优势,但与编辑 .config 文件相比,您在部署新程序集时更有可能意外引入新错误。如果您在一家由不值得信赖的非程序员负责配置文件的商店工作,那么编译一些内容确实可以减少输入错误数据的机会。

  3. 数据库配置表 - 从数据库中获取配置数据比从配置文件中检索配置数据更复杂。另外,您必须小心数据锁和其他数据库优点。但是,如果您需要在运行时编辑设置而不触发应用程序池回收(不太可能),那么这是您最好的选择。

  4. XML 文件 - 使用 web.config 更容易,但这允许您部署独立于 web.config 的文件,因此它不太可能包含潜在危险的副作用。

In order of preference:

  1. Web.config - The main benefit of using web.config is that the application pool is automatically recycled when the file changes. Also, you have the well-known System.Configuration API for accessing the data. You shouldn't have to muck around with a separate XML file and monitor it for changes when ASP.NET already has support for configuration files.

  2. Constants file - This has the same app pool recycling benefits as the web.config, but it's more likely that you could accidentally introduce new bugs when deploying new assemblies than editing .config files. If you work in a shop where untrustworthy non-programmers are in charge of the config files, having something compiled in does reduce the chance of entering bad data.

  3. Database config table - Fetching configuration data from a database is more complicated than retrieving it from a config file. Plus, you have to be careful about data locks and other DB goodness. However, if you need to edit settings at runtime without triggering app pool recycling (unlikely), this is your best bet.

  4. XML file - It's easier to use web.config, but this allows you to deploy a file independent of the web.config so it is less-likely to contain potentially-hazardous side-effects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文