为啥使用 app.config 来存储配置数据?
Posted
技术标签:
【中文标题】为啥使用 app.config 来存储配置数据?【英文标题】:Why use app.config to store config data?为什么使用 app.config 来存储配置数据? 【发布时间】:2010-11-05 23:19:36 【问题描述】:我目前正在完成由其他人发起的申请。他将 app.config 用于某些设置,并将自定义 xml 文件用于其他部分。这让我抓狂,我想将配置整合到一个文件中。
但我不确定是将所有内容移入 app.config 并丢弃自定义 xml 文件,还是将所有内容移入其他文件而忘记 app.config。
我可以看到两个参数,每个选项一个:
-
使用 Visual Studio 提供的标准方式比我更容易维护。
我可以根据我自己的 xml 架构验证自定义文件,因此如果配置文件包含所有必需的数据等,我会外包大量测试。
但我敢肯定,我现在想不到的事情还有很多。这就是我要问的原因:
与“传统”配置文件相比,使用 app.config 存储配置有哪些优点或缺点?
【问题讨论】:
【参考方案1】:App.config 是默认值,并且在大多数情况下是处理应用程序配置的最佳方式,因为当您需要解析文件以获取值以及文件变得足够大时,它会产生成本成为一个问题。
对于具有大型 web.config 文件的 Web 应用程序来说,这更是一个问题,每次您发出请求时,都会解析 web.config 并且这可能会产生负担,您会在一些 ORM 映射器中看到这一点。
【讨论】:
【参考方案2】:如果您的项目的生命周期需要将配置从一个环境转移到另一个环境,那么将配置拆分为不同的文件非常有用。
例如,当开发人员处理代码时,您可能希望应用指向“devsql”框。当需要进行 QA 时,代码会部署到临时服务器,并且您希望应用程序指向“stagingsql”。
如果您将所有配置保留在 app.config 中,并且对 app.config 的开发版本进行了设置更改,它将被复制并破坏暂存版本 - 现在您的 QA 人员指向开发数据库。
通过将“database.xml”与“app.config”分开,您可以考虑不同环境之间的差异,但仍允许对配置文件的更改从每个环境流向下一个环境,而不必担心覆盖自定义。
【讨论】:
配置文件也可以根据上下文进行转换。 olegsych.com/2010/12/config-file-transformation 很方便!【参考方案3】:App.config 对连接和日志配置有很好的支持,您将在几乎所有应用程序中使用它们。重写它们可能会给你带来很多工作。此外,如果您在 app.config 上使用“sectionGroup”,则可以具有一定的结构灵活性。
但在做某事之前,我会问创建自定义配置文件的人为什么要这样做。在某些不寻常的情况下,app.config 会给您带来一些麻烦,例如您想通过 Assembly.Load 加载另一个 DLL(带有自己的 app.config)。在这种情况下,您需要将两个配置合并到一个 app.config 中,并祈祷它们不会有任何具有相同密钥的配置。
在 webtests 中,你不能覆盖 web.config 配置,所以它也会带来一些麻烦,这取决于你想要做什么。
但是恕我直言,只有在不寻常的情况下,app.config 才能使其正常工作。在最常见的情况下,我认为不值得创建自己的配置框架。
【讨论】:
【参考方案4】:在 Web.config 中创建类来定义自己的配置部分非常容易,这将使您能够对配置数据进行强类型访问,允许您为配置信息定义一种模式等。请参阅例如,this article [4guysfromrolla.com] 了解实施细节。
【讨论】:
【参考方案5】:我同意 XML 序列化程序与“设置”类相结合是存储设置的好地方,尤其是在您有很多自定义类型或对象的情况下。
【讨论】:
【参考方案6】:简单性和程序可读性。
App.config 是 .NET 中用于存储配置的常用方法,因此其他程序员可能会看到它。它存储在 XML 中,因此与 XML 配置文件相比不会有任何性能。
它还处理保存 app.config 的位置(文档和设置/用户名/本地设置/应用程序数据/您的应用/)并自动保存配置根据您的应用程序的位置和版本,允许同一应用程序的多个版本共存。
我想说 app.config 和自定义 XML 文件都不需要,因此将两者结合起来可能是个好主意。
【讨论】:
其实和C#没什么关系。这是 .NET 中存储配置的常规方式。【参考方案7】:恕我直言,app.config 不是一种非常方便的存储配置数据的方式,主要是因为这两个原因:
您无法控制文件的位置 您无法定义自己的结构来组织配置设置我更喜欢使用我自己的配置类,我使用 XML 序列化加载和保存它。您仍然可以获得强类型设置的好处,而且它更加灵活,因为您可以定义任何您想要的结构
【讨论】:
是的,控制较少的部分也困扰着我。不确定这是否超过了 app.config 是规范的事情这一事实...... 您可以创建自己的配置类。你是什么意思你不能定义自己的结构?顺便说一句,无法控制位置是一件好事。这意味着它只在一个地方,您不必去寻找它。 我无法控制某事从来都不是好事。如果我不想控制某些东西,可以使用智能默认值 ;-) @John :关于自定义配置部分,您是对的,但我仍然认为编写轻量级 POCO 类比从 ConfigurationSection 继承更快、更灵活。关于文件的位置...好吧,我希望能够轻松找到文件以手动编辑它 您可以使用 ConfigurationSection 并仍然使用 POCO 类。如果您有兴趣,我刚刚在这里写了博客-northdownsolutionslimited.co.uk/post/…【参考方案8】:使用 app.config 的主要好处是它是 .NET 应用程序存储其配置的默认支持方式。任何使用该应用程序或从您那里继承它的人总有一天会感谢您使用既定标准而不是“自行开发”。
此外,.NET 框架支持使用、编写、创建、修改 app.config 文件 - 如果您使用自己的方案,您将不得不重新发明***很多次。
所以我肯定会推荐使用 app.config - 这是在 .NET 中进行配置的THE方式,也是一个被广泛接受和支持的标准。
马克
【讨论】:
您还可以轻松加密 app.config 的各个部分。 @RichardOD 如果您可以添加一个详细说明如何进行您提到的加密的链接,那就太好了。 @Adam Tuttle,这是链接msdn.microsoft.com/en-us/library/89211k9b%28VS.80%29.aspx以上是关于为啥使用 app.config 来存储配置数据?的主要内容,如果未能解决你的问题,请参考以下文章
在 web.config 或 app.config 中存储分层应用程序设置
为啥我需要在 Azure 管理门户中而不是在我的 WebJob 的 App.config 中为 WebJobs 配置连接字符串?
web.config 覆盖 app.config ...为啥?