配置设置的最佳实践
我想知道存储配置设置的一些最佳实践。 假设您有一些跨多个应用程序共享的设置。 我听说过存储这些需要共享的设置类型（XML 文件）的好方法和坏方法。
只是想知道在跨版本维护应用程序设置以简化部署方面什么是好的标准。
我想我会从两个场景来看待这个问题：
- 内部应用程序（无论是大型 .com 还是小型管理应用程序）。
- 创建供其他人使用的 API 时，当您不知道将在其应用程序中使用您的 API 的使用者的最终值是什么时，如何引用配置设置。
已添加-1：
谢谢。 我听说过一些恐怖故事，有些地方在跨多个应用程序管理配置设置时遇到了噩梦。 我不是构建人员，所以我不知道为什么，但我想绝对尝试确保我现在在 web.config 与自定义配置文件等场景类型方面理解它。
Added-2：
当您创建要使用的 API 时该怎么办？ 假设有一个类将提取某些配置信息，但这些端点（属性）在客户端使用您的 API（特别是 C#/.NET）之前不会定义？ 您将在哪里以及如何在您创建的配置类（例如“ApplicationDefinitions”）中设置这些属性？
I'm wondering about some best practices out there on storing configuration settings. Let's say you have some settings shared across several applications. I've heard both good and bad ways to store these types of settings that need to be shared (XML files).
Just wondering on what is a good standard in terms of maintaining app settings across builds for easier deployment.
I guess I'm looking at this from 2 scenarios:
- An application in-house (whether it's a big .com or small admin app).
- When creating an API for others to consume, how to reference configuration settings when you do not know what the end values will be from the consumer who will be using your API in their application.
Added-1:
Thanks. I've heard horror stories where some places have a nighmare managing configuration settings across multiple applications. I am not a build guy so I do not know why but I want to definitely try to make sure I understand it now in terms of web.config vs. custom config files, etc. type of scenarios.
Added-2:
And what about when you are creating an API to be consumed. You have lets say a class that is going to pull certain config information but those endpoints (properties) are not defined until the client consumes your API (specifically C#/.NET)? Where and how would you set those properties in lets say a Configuration Class that you create such as "ApplicationDefinitions"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果它跨多个应用程序，您可以（非常小心）将设置放入 machine.config 中。
或者，您可以拥有一个单独的通用配置设置存储库文件，每次构建 Web 应用程序/解决方案时，该文件都会被读入并用于生成新的 web.config。
If it's across several applications, you can (very carefully) put the settings into machine.config.
Or you can have a separate common config setting repository file that gets read in and used to generate a new web.config every time you build your web application / solution.
我们必须支持多个 UAT（用户验收测试）、生产、开发和灾难恢复环境。
理想情况下，这些信息都位于一个巨大的 LDAP 服务器中。
在现实世界中，我们编写了一个 ANT 任务，它使用 Jakarta-Velocity 作为模板引擎。 这会从单个模板文件生成多个文件（UAT、DEV、PROD、DR）。
我们有一个用于所有常见内容的中央文件和用于单个应用程序的较小文件。 任何一个应用程序的命令行都需要知道它是否是正在运行的 UAT/DEV.. 系统等，然后加载到公共文件和应用程序特定文件中。
这在实践中非常有效，我们已经使用了大约 8 年。 我见过很多其他人试图在他们的所有环境中处理多个应用程序文件，但这并不漂亮。 经常会犯错误。
We have to support multiple UAT (User Acceptance Tests) , production, development and disaster recovery environments.
Ideally this information would all be in one giant LDAP server..
In the real world we have written an ANT task that uses Jakarta-Velocity as a templating engine. This generates multiple files (UAT, DEV, PROD, DR) from a single template file.
We have a central file that is used for all common stuff and smaller files for individual applications. The command line for any one app need to know whether it is a UAT/DEV.. system etc that is being run, it then loads in the common file and the app specific file.
This works very well in practice and we have been using it for about 8 years. I have seen a lot of other people trying to juggle multiple app files for all their environments and it is NOT pretty. Mistakes are often made.
我尝试做的是将部署到不同环境时不同的配置设置分成单独的文件，按逻辑功能组织，然后不将这些文件包含在部署脚本中...
如果您在 .Net 中编码，那么跨多个应用程序通用的设置可以存储在 machine.config 中...再次，不要将它们直接放在 machine.config 中，而是创建对单独文件的引用（使用自定义定义的 configSection 和 configSource=" “属性，创建对该单独文件的间接引用...
What I try to do is separate the config settings that will be different for deployments to different environments into separate files, organized by logical functions, and then NOT include these files in the deployment scripts...
If you're coding in .Net, then settings that are in common across multiple apps can be stored in machine.config... again, don't put them directly in machine.config, but create a reference to a separate file (using a custom defined configSection and configSource="" attribute, to create an indirect reference to that separate file...