从 app.config 注入连接字符串与从 BaseDataProvider 类中读取它答案

【问题标题】：Inject connectionstring from app.config vs read it from a BaseDataProvider class从 app.config 注入连接字符串与从 BaseDataProvider 类中读取它
【发布时间】：2012-02-19 22:33:06
【问题描述】：

你看到从 Global.asax.cs 注入数据库连接字符串有什么好处吗？ ASP.NET MVC 中的类与从访问 app.config 文件的 BaseDataProvider 类中读取连接字符串的方法相比？

【问题讨论】：

如果您将连接字符串注入 MVC 的某些部分（例如控制器），那么您显然违反了单一职责原则。这将导致难以测试、难以维护的代码。如果将连接字符串注入到Controller中，这意味着控制器直接查询数据库，这不是Controller的工作。这是存储库或工作单元的工作。控制器应该依赖于为它做数据库的东西。

标签： c# asp.net-mvc dependency-injection connection-string app-config

【解决方案1】：

我更喜欢使用构造函数注入来注入任何需要的对象（只要可能）。

我看到的一个小优势是关于类的依赖关系的透明度。

例如，如果您尝试在测试工具中实例化一个类（在进行集成测试时）：

在第一种情况（构造函数注入）中，您会立即看到它需要一个连接字符串并提供一个
在第二种情况下，您实例化类（可能使用默认构造函数），经过反复试验发现它取决于设置的 ConnectionString 属性

更新： 构造函数注入方法的另一个优点是，它将类本身与从 app.config 中获取连接字符串的机制解耦。

这可能会在您现在甚至没有想到的未来场景中启用。

例如，在我目前从事的一个项目中，我有一个具有数据库访问权限的组件，并且我在多个上下文中重用了它。在其中一些中，它使用来自配置文件的标准连接字符串，而在另一些中，我有另一个组件根据某些条件决定使用哪个连接字符串。

如果您选择第二种方法，则需要更改代码以支持此类功能。

【讨论】：

+1 我也会选择注射策略。不要隐藏你的依赖，否则它们迟早会咬你。

【解决方案2】：

我通常采用混合方法，这样我的 BaseDataProvider 类有一个空的构造函数，默认为存储在配置中的任何内容，但在我需要非默认连接的情况下被覆盖以接受 connString。

然后我的 Global.asax 类包含必要的逻辑来确定在给定情况下他们可能需要什么连接字符串。例如，假设您的 Web 应用程序在全球范围内部署在世界各地的服务器上，您希望连接到最近的可用数据库服务器以避免延迟问题。所以在用户登录时，我会弄清楚我的用户在哪里，然后用适当的连接设置它们

【讨论】：