Question

这里有一个长期运行的习惯，我工作的连接字符串存在于web.config中，Sql Connection对象在带有该连接字符串的using块中实例化并传递给DataObjects构造函数（通过CreateInstance方法作为构造函数是私有的）。像这样：

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

这对我来说都有气味......我不知道。 DataLayer类库是否应该负责Connection对象和Connection字符串？我很高兴知道其他人正在做什么或者有关这些设计决定的任何好的在线文章。

请考虑我们所处理的项目始终是Sql Server后端，并且极不可能改变。所以工厂和供应商模式不是我追求的。它更多的是责任在哪里以及应该为数据层操作管理配置设置。

Answer 1

我喜欢在我的数据访问层中编写类，以便它们有一个构造函数，它将IDbConnection作为参数，另一个构造函数接受（连接）字符串。

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

Answer 2

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

我认为，我会有一个提供某些DataInput的数据层，即带有条件并返回DataObjects的东西。这样的DataInput现在知道“嘿，这个DataObjects存储在THAT数据库中，并且使用Configurations，我可以使用一些连接字符串从那里获取SQL-Connection。

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

Answer 3

这是一种“气味”是相对的。如果您非常确定将这段特定代码与SQL Server和web.config连接字符串条目相结合，那么它就完全可以了。如果你没有进入这种耦合，我同意它是一种代码味道并且是不可取的。

在.NET中具有单独数据访问层的分层设计中，应该管理连接字符串吗？

3 个答案: