ConfigurationManager.OpenExeConfiguration（）vs XML文件

Question

有人可以告诉我使用ConfigurationManager类的优势，该类加载了一个配置文件来进行操作VS一个XML文件和你构建的类来自己阅读吗？

最近，我构建了一个继承自ConfigurationSection的类，以便在app.config中操作自定义部分。与打开和读取XML文件相比，这是相当多的工作。

有些人选择了第一种方法，有些人选择了第二种方式。

什么是好的做法？

Answer 1

这是一个老问题，但是到底是什么......所以是的，在编写配置节和元素时会有相当多的代码开销，但与使用自己的类与XML序列化器相比，你得到的包括：< / p>

• 键入转换和验证：如果您的某个配置设置是“类型”（可能在您的配置中存储了您需要为某个提供程序创建的实现类型），那么ConfigurationManager将不仅会转换任何内容在.config文件中写入System.Type，但您也可以在ConfigurationElement属性上添加验证属性，如“SubclassTypeValidatorAttribute”，它将检查给定类型是否来自您的基本提供程序类/接口。您当然可以添加自己的验证器，这样在您的其余代码中，您只需“获取”配置，并且您知道一切都是有效的。
• 多级设置层次结构：您可以在机器，应用程序或用户级别上存储设置，这为您提供了一种处理默认设置与特定于用户的设置的机制。您还可以使用API​​从自定义位置加载配置。
• 配置文件中没有重复：如果你正在使用其他.NET功能，如TraceSources和东西，那么配置已经在.config文件中了（假设您正在解决问题，并且您想打开一些调试跟踪默认情况下关闭...你只需修改.config即可。如果您使用自己的配置文件进行自定义设置，那么最终会得到2个配置文件，这样做不太好。

可能还有其他好处，但到目前为止我想到的是这一点。

Answer 2

这只是一种向配置文件读取和写入数据的推荐且更简单的方法。使用XML DOM的程度太低了。

如果需要，您始终可以使用section.SectionInformation.GetRawXml（）从ConfigurationSection获取原始xml配置。同样使用SetRawXml来设置它。

使用ConfigurationManager时有一些问题，例如当您使用OpenMappedExeConfiguration加载配置文件时，您将获得一个“合并”的内存配置，并且包含来自machine.config的部分。您可以使用section.ElementInformation.Source.Equals（source.FilePath）检查某个部分是否来自您提供的文件。

参考：MSDN