在applicationSettings中放入连接字符串有任何错误

本文关键字：字符串 任何 错误 连接 applicationSettings | 更新日期: 2023-09-27 18:21:20

.NET支持多种存储配置设置的方法已经有很长一段时间了，这导致了很多混乱。MSDN上搜索"C#中的设置"的前三名已经有十年的历史了（这个古老网站上的许多相关问题[2]也有6-7年的历史），这也于事无补。现在真的很难确定哪些早期的建议已经被否决了。

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

  1. 这似乎是MSDN（以及此处）上当前推荐的方法
  2. AppSettings元素自.NET 4+*起似乎已被弃用（主题为"不再可用"；但请参阅该页上的"其他版本"。）[*尽管令人困惑的是，AppSettings属性仍然受支持]
  3. 我更喜欢在设计器工具中编辑设置，而不是在xml编辑器中
  4. 我更喜欢强类型设置

但是，现在我需要决定将连接字符串放在哪里。MSDN上最新的文档（这里还有SO和CP）似乎仍然建议使用app.config的<connectionStrings>部分。但是从代码中访问它需要使用旧语法，我现在认为它与appSettings一起过时了。换句话说，用旧语法读取app.config文件的一部分是没有意义的：

ConfigurationManager.ConnectionStrings["MydDBConnName"];

以及具有新语法的同一文件的另一部分：

Properties.Settings.Default.myOtherSetting;

此外，它使我无法在设计器中编辑字符串。

那么，底线是：有什么理由不在ApplicationSettings元素中标准化我的所有配置设置（包括连接字符串）吗？

在applicationSettings中放入连接字符串有任何错误

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

然而，在现实中，支持这种灵活性意味着你必须使用与提供者无关的SQL语句（这意味着你不能做没有标准SQL语法的日期数学之类的事情），并且需要更多的"管道"代码来创建正确类型的对象。你可以在这里看到一些例子。

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

我建议您保持类设置与源代码无关。

例如，如果有一个DatabaseContext需要一个连接字符串，那么在构造函数中注入该基元依赖项。不要直接通过ApplicationSettings查找连接字符串。

从类中定位基元依赖项（例如设置）与使用服务定位器反模式完全相同。

应用程序中唯一应该获取设置（例如连接字符串）的位置是Composition Root。因此，您可以在这里从ApplicationSettings获取设置，并将它们注入到您的类中。

如果您想使用不同的方式存储/检索设置，您可以稍后更改主意。

正如您在链接到的页面上所读到的那样，使用<connectionStrings>的主要好处是它提供了加密字符串的机制，从而不会将密码保持在明文中。如果你使用Windows身份验证来连接到数据库，那么我想你不需要它，而且你把连接字符串放在哪里也无关紧要。这只是一种标准的方法。

然而，我相信你说"旧语法"被弃用是错误的。例如，<appSettings>仍然有文档记录，它只是更改了地址。如果真是这样的话，它会带来大破坏。这不是我的领域，但我认为你所说的"新语法"是访问桌面应用程序中设置的方式，而服务器端应用程序中没有。

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

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

相关文章：