为什么使用app.config存储配置数据?

使用app.config的主要好处是它是.NET应用程序存储其配置的默认支持方式。有一天,任何使用或继承该应用程序的人都会感谢您使用已建立的标准,而不是“滚动您自己的标准”。

此外,.NET框架还支持使用、编写、创建、修改app.config文件-如果您使用自己的方案,则必须多次重新发明轮子。

所以我绝对推荐使用app.config-它是 这个 在.NET中进行配置的方法,以及广泛接受和支持的标准。

马克

如果项目的生命周期使配置从一个环境移动到另一个环境,那么将配置拆分为不同的文件非常有用。

例如,当开发人员正在处理代码时,您可能希望应用程序指向“devsql”框。到了QA的时候,代码被部署到一个临时服务器上,您希望应用程序指向“stagingsql”。

如果将所有配置保存在app.config中,并且对app.config的dev版本进行了设置更改,则会复制该版本,并删除临时版本-现在,您的QA人员将指向dev数据库。

通过将'database.xml'与'app.config'分开,您可以允许不同环境之间的差异,但仍然允许对配置文件的更改从每个环境流到下一个环境,而不必担心覆盖自定义项。

imho app.config不是一种非常方便的存储配置数据的方法,主要是因为以下两个原因:

• 您无法控制文件的位置
• 不能定义自己的结构来组织配置设置

我更喜欢使用自己的配置类,使用XML序列化加载和保存。您仍然可以获得强类型设置的好处,而且它更加灵活,因为您可以定义您想要的任何结构。

app.config对连接和日志配置有很好的支持,您将在几乎所有应用程序中使用这些配置。重写它们可能会给你带来很多工作。此外,如果在app.config中使用“sectiongroup”,则可以具有一定的结构灵活性。

但是在做一些事情之前,我会问创建自定义配置文件的人为什么要这样做。有一些不寻常的情况,app.config会给您带来一些麻烦,比如,如果您想通过assembly.load加载另一个dll(使用它自己的app.config)。在这种情况下,您需要将这两个配置合并到一个app.config中,并祈祷它们不会有任何具有相同密钥的配置。

在Webtests中,您不能覆盖web.config配置,因此它也会带来一些麻烦,取决于您想做什么。

但是,imho,只有在不寻常的情况下,app.config才不能很好地工作。在大多数常见的情况下,我认为不值得创建自己的配置框架。

简单性和程序可读性。

app.config是.NET中用于存储配置的普通方法,因此它的其他程序员可能也会看到它。它存储在XML中,因此与XML配置文件相比不会有任何性能。

它还处理保存app.config的位置(文档和设置/ 用户名 /本地设置/应用程序数据/ 你的应用程序 /)并根据应用程序的位置和版本自动保存配置,以允许同一应用程序的多个版本共存。

我想说不需要app.config和自定义XML文件,因此将两者结合可能是一个好主意。

我同意XML序列化程序与“settings”类结合在一起是存储设置的好地方,特别是当您有很多自定义类型或对象时。

在web.config中创建类来定义您自己的配置节是非常容易的,这将为您提供对配置数据的强类型访问,允许您为配置信息定义一种模式等。请参见,例如, this article [4guysfromrolla.com]了解实现详细信息。

app.config是默认配置,在大多数情况下,它是处理应用程序配置的最佳方法,尽管它说当您需要解析文件以获取值时会有成本,当文件足够大时,这就成为一个问题。

对于具有大型web.config文件的web应用程序来说,这是一个更大的问题,每当您发出请求时web.config就会被解析,这可能会使您头疼,您将在一些ORM映射器中看到这一点。