将连接字符串放入 applicationSettings 有啥问题吗？ [复制]

Posted 2023-03-04

【中文标题】将连接字符串放入 applicationSettings 有啥问题吗？ [复制]

【英文标题】：Anything wrong with putting connection strings in applicationSettings? [duplicate]将连接字符串放入 applicationSettings 有什么问题吗？ [复制]

【发布时间】：2016-02-11 20:26:55

【问题描述】：

.NET 已经支持多种存储配置设置的方法，这导致了很多混乱。搜索"Settings in C#" over on MSDN 的前三名已存在 10 年（而且这个古老网站上的许多 related questions [2] 也存在 6-7 年），这无济于事。很难确定哪些早期建议已被弃用。

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

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

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

ConfigurationManager.ConnectionStrings["MydDBConnName"];

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

Properties.Settings.Default.myOtherSetting;

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

所以底线：是否有任何理由不对ApplicationSettings 元素中的所有配置设置（包括连接字符串）进行标准化？

【问题讨论】：

在这种情况下“标准化”是否意味着您的类将通过使用ApplicationSettings直接获取连接字符串/其他设置？

@YacoubMassad：是的，我想获取所有设置，包括使用语法Properties.Settings.Default.x的连接字符串

你是enitiy框架吗？还是直接ado.net？

@BlackFrog：没有框架。直接 C#

@IanP：我看到了那个帖子（甚至链接到它）。但它已经快 7 年了，并且所选答案指向了将近 10 年的文章。

【参考方案1】：

正如您在链接到的页面上必须阅读的那样，使用<connectionStrings> 的主要好处是它提供了加密字符串的机制，以便不以明文形式保存密码。如果您使用 Windows 身份验证连接到数据库，那么我猜您不需要它，而且您将连接字符串保存在哪里并不重要。这只是执行此操作的标准方式。

但是，我认为您说“旧语法”已被弃用是错误的。例如，<appSettings> 仍被记录在案，it just changed the address。如果是这样，那将带来严重破坏。这不是我的领域，但我认为您所说的“新语法”是在桌面应用程序中访问设置的方式，而在服务器端应用程序中是没有的。

【讨论】：

感谢您对文档链接的澄清。 （我已通知this page的维护者，链接到旧地址。）

【参考方案2】：

我建议你保持你的类设置与源无关。

例如，如果您有一个需要连接字符串的DatabaseContext，则在构造函数中注入该primitive dependency。不要直接通过ApplicationSettings定位连接字符串。

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

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

如果您想使用不同的方式存储/检索设置，这允许您稍后改变主意。

【讨论】：

当然，但它是我目前正在创建的组合根（或更具体地说，数据访问层），所以这并不能真正回答我的问题。 （我必须在代码中获取设置数据somewhere）。组合根隔离了问题，但并没有消除它。

@kmote，您的数据访问层是否存在于自己的应用程序/进程中？

目前，是的。 （它只是一个带有几个简单方法的类）。但恐怕我看不出这与我的问题有什么关系。

根据您在我询问“标准化”的含义时给出的回答，我认为（错误地，现在在我看来），您在问是否应该使用 ApplicationSettings从你的课上。我的回答是告诉你为什么不这样做。

哦，是的，我现在看到了混乱。我误解了你原来的问题。谢谢你的澄清。

【参考方案3】：

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

【参考方案4】：

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

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

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

【参考方案5】：

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