Question

.NET已经支持了很多方法来存储配置设置很长一段时间，这导致了很多混乱。搜索"Settings in C#" over on MSDN的前三次点击是十年之久并没有帮助（这个值得尊敬的网站上的related questions [2]中的许多也是6到7年旧）。很难确定哪些早期建议已被弃用。

在我的项目中，我选择使用ApplicationSettings（而不是AppSettings），因为：

这似乎是current recommended approach on MSDN（和here）。
AppSettings元素appears to be deprecated as of .NET 4+ *（主题为＆＃34;不再可用＆＃34 ;;但请参阅＆＃34;其他版本＆＃34;在该页面上。）_{[ *虽然令人困惑，但AppSettings Property is still supported]}
我更喜欢在设计器工具中编辑设置，而不是在xml编辑器中编辑。
我更喜欢强类型设置。

但是，现在我需要决定放置连接字符串的位置。关于MSDN（和here on SO以及CP）的最新文档仍然建议使用<connectionStrings>的{{1}}部分。但是从代码中访问它需要使用旧语法，我现在认为它与appSettings一起过时了。换句话说，使用旧语法读取app.config文件的一部分是没有意义的：

app.config

使用new语法的同一文件的另一部分：

ConfigurationManager.ConnectionStrings["MydDBConnName"];

另外，它阻止我能够在设计器中编辑字符串。

所以底线：有没有理由不在Properties.Settings.Default.myOtherSetting;元素中标准化我的所有配置设置（包括连接字符串）？

Answer 1

ConnectionStrings部分不仅允许您在配置中定义连接字符串，还允许您选择提供商，因此您可以编码（理论上）使用DbConnection，DbCommand等的任何子类

但实际上，支持这种灵活性意味着您必须使用与提供程序无关的SQL语句（这意味着您不能执行日期数学等没有标准SQL语法的事情），并且需要更多“管道“用于创建正确类型的对象的代码。您可以看到一些示例here。

如果您只支持一个数据库提供程序（SQL Server，Oracle，ODBC，OleDB），那么在字符串应用程序设置中使用ConnectionStrings并没有什么好处。

Answer 2

我建议你保持你的课程设置 - 源不可知。

例如，如果您的DatabaseContext需要连接字符串，则在构造函数中注入primitive dependency。不要通过ApplicationSettings直接找到连接字符串。

从您的类中查找原始依赖项（例如设置）与使用Service Locator anti-pattern完全相同。

应用程序中唯一应该获取设置的位置（例如连接字符串）是Composition Root。因此，您可以在此处获取ApplicationSettings的设置并将其注入您的课程。

如果您想使用其他方式存储/检索设置，这可以让您稍后改变主意。

Answer 3

由于您必须阅读链接到的页面，因此使用<connectionStrings>的主要好处是它提供了加密字符串的机制，以便不将密码保存为明文。如果您使用Windows身份验证连接到数据库，那么我猜您不需要它，并且在保持连接字符串的位置并不重要。这只是一种标准的做法。

但是，我相信你错误地说这句老语法＆＃39;已弃用。例如，<appSettings>仍然记录在案，it just changed the address。它会带来浩劫。这不是我的领域，但我认为你所说的是新语法＆＃39;是在桌面应用程序中访问设置的方式，您在服务器端应用程序中没有它。

Answer 4

我认为ApplicationSettings元素仅用于组织。如果您注意到Entity Framework或大多数其他数据库连接，它们会将它们存储在ConnectionStrings元素下的配置中。我唯一担心的是存储任何类型的敏感数据，如连接用户和密码。解决这个问题的常用方法是允许Windows身份验证处理连接。

Answer 5

您所制作的标准。例如，在我当前的工作环境中，特定应用程序中更改的唯一信息是服务器名称。我们有dev / test / prod服务器。因此，我们只将SQL Server名称存储在配置文件中。数据库名称不会更改。我们只是从配置文件中读取数据库服务器，并在应用程序中构建字符串。

在applicationSettings中放置连接字符串有什么问题吗？

5 个答案: