在.NET中使用单独的DataAccess图层的分层设计中应该如何管理连接字符串？

Question

这里有一个很长的运行习惯，我工作的连接字符串居住在web.config中，Sql Connection对象在使用该连接字符串的块中实例化并传递给DataObject构造函数（通过CreateInstance方法构造函数是私有的）。事情是这样的：

using(SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString)) 
{ 
    DataObject foo = DataObject.CreateInstance(conn); 
    foo.someProperty = "some value"; 
    foo.Insert(); 
} 

这一切都闻到我..我不知道。 DataLayer类库不应该负责连接对象和连接字符串吗？我很想知道别人在做什么或者有关这些设计决策的好的在线文章。

请考虑我们的项目始终是Sql Server后端，而且这是不太可能改变的。所以工厂和供应商模式不是我所追求的。它更多关于责任的位置以及应该如何管理数据层操作的配置设置。

Answer 1

我喜欢以使它们具有一个构造函数的的IDbConnection作为参数，而另一个采用一个（连接）字符串在我的数据访问层编码的类。

通过这种方式，调用代码可以构建自己的SqlConnection并将其传入（便于集成测试），模拟IDbConnection并将其传入（便于进行单元测试）或从配置文件中读取连接字符串（例如web.config）并通过。

Answer 2

这是一个“气味”是相对的。如果你很确定将这段特定的代码连接到SQL Server和一个web.config连接字符串条目，那么它完全可以。如果你不喜欢这种耦合，我同意它是一种代码味道，并且是不可取的。

Answer 3

嗯，我想我同意数据层应该负责管理这样的连接字符串，所以更高层不需要担心这一点。但是，我不认为SQLConnection应该担心连接字符串来自哪里。

我想，我想有一个数据层提供一定DataInputs，也就是事情需要条件并返回数据对象。这样的DataInput现在知道“嘿，这个DataObjects存储在THAT数据库中，并且使用配置，我可以使用一些连接字符串从那里获得一个SQL连接。

这样你就封装了整个过程“数据对象来自哪里？”以及数据层的内部结构仍然可以正确测试（并且，作为副作用，您可以轻松地使用不同的数据库，甚至同时使用多个不同的数据库。刚刚弹出的这种灵活性是一个好兆头（tm））