5

我想知道一些关于存储配置设置的最佳实践。假设您在多个应用程序之间共享了一些设置。我听说过存储这些需要共享的设置（XML 文件）的好方法和坏方法。

只是想知道在跨构建维护应用程序设置以更容易部署方面什么是好的标准。

我想我是从 2 个场景来看这个的：

  1. 内部应用程序（无论是大型 .com 还是小型管理应用程序）。
  2. 在创建供其他人使用的 API 时，当您不知道将在其应用程序中使用您的 API 的消费者的最终值是什么时，如何引用配置设置。

添加-1：

谢谢。我听说过一些可怕的故事，有些地方在管理多个应用程序的配置设置时遇到了噩梦。我不是一个构建人员，所以我不知道为什么，但我想肯定地尝试确保我现在在 web.config 与自定义配置文件等类型的场景方面理解它。

添加-2：

当您创建要使用的 API 时又如何呢？您可以说一个要提取某些配置信息的类，但是直到客户端使用您的 API（特别是 C#/.NET）才定义这些端点（属性）？您将在哪里以及如何设置这些属性，比如说您创建的配置类，例如“ApplicationDefinitions”？

4

3 回答 3

1

我们必须支持多个 UAT（用户验收测试）、生产、开发和灾难恢复环境。

理想情况下，这些信息都在一个巨大的 LDAP 服务器中。

在现实世界中，我们编写了一个使用 Jakarta-Velocity 作为模板引擎的 ANT 任务。这会从单个模板文件生成多个文件（UAT、DEV、PROD、DR）。

我们有一个用于所有常见内容的中心文件和用于单个应用程序的较小文件。任何一个应用程序的命令行都需要知道它是否是正在运行的 UAT/DEV.. 系统等，然后它会加载公共文件和应用程序特定文件。

这在实践中效果很好，我们已经使用了大约 8 年。我见过很多其他人试图为他们的所有环境处理多个应用程序文件，但这并不漂亮。经常犯错误。

于 2008-12-29T21:27:35.973 回答
1

如果它跨越多个应用程序，您可以（非常小心地）将设置放入 machine.config。

或者，您可以拥有一个单独的通用配置设置存储库文件，每次构建 Web 应用程序/解决方案时，该文件都会被读取并用于生成新的 web.config。

于 2008-12-29T19:50:49.007 回答
0

我尝试做的是将部署到不同环境的不同配置设置分离到单独的文件中，按逻辑功能组织，然后不将这些文件包含在部署脚本中......

如果您在 .Net 中进行编码，则可以将跨多个应用程序的通用设置存储在 machine.config 中......再次，不要将它们直接放在 machine.config 中，而是创建对单独文件的引用（使用自定义的 configSection 和 configSource="" 属性来创建对该单独文件的间接引用...

于 2008-12-29T19:51:29.100 回答