Question

我正在构建ASP.NET MVC 5应用程序。

我读到了存储库和工作单元（UoW）模式here。

这些示例使用Entity Framework，它本身添加了高级抽象。

我使用的是ADO.NET而不是EF。我想知道：

Repository和UoW模式是否与ADO.NET有任何关系？
我的存储库和UoW如何看待ADO.NET？任何样品？
我可以为Repository添加一个单独的类库，还是让它成为DAL的一部分？

Answer 1

我编写了一个blog post，它教你如何编写与驱动程序无关的代码，以及如何使用普通的ADO.NET实现Uow / Repository模式。

在这个答案中包含它有点太长了，但基本上IDbtransaction代表你的单位工作（或包含在一个工作中），每个存储库都会在它的构造函数中使用事务或UoW。

使用IDbTransaction

创建命令

using (var cmd = transaction.Connection.CreateCommand())
{
    cmd.Transaction = transaction;

    //do a CRUD operation here.
}

Answer 2

当您谈论标准ADO.NET时，工作单元模式更为重要，因为您必须绝对确保您打开的连接仅在所需的时间段内打开，通过将连接内部包裹起来实现using陈述。
ADO.NET中的工作单元看起来像这样：

using (SqlConnection con = new SqlConnection(//connection string) { using (SqlCommand cmd = new SqlCommand(storedProcname, con)) { //... } }

当您使用using语句来涵盖您的工作单元时，您可以放心，SqlConnection.Dispose()方法会调用SqlConnection.Close()方法和SqlCommand.Dispose()来电SqlCommand.Close()。

如上一个问题所述，如果您愿意，可以将这两个分开，但我个人认为它们应该是相同的。

Answer 3

如果您查看模式的definitions以及支持它们所需的模式，您会看到，如果您自己开始实施这些模式，那么您将永远不会徘徊从创建自己的ORM。虽然这是一项非常有趣的任务，但在考虑NHibernate和EntityFramework时，它永远不值得。

然而，为了回答你的问题，我发现Fowler的PoEAA书在学习如何编写我自己的UoW，DataMappers和Repositories方面非常宝贵，所有这些都基于ADO.Net。它是由一个显然是真实地完成它的人写的，犯了所有错误然后记录下来，以便你不必这样做。我还没有阅读你所链接的文章，但是我经常担心使用这样的文章，因为它们只是表现出对这种模式的表面层面的考虑。

Answer 4

前段时间我写了blog post为什么你所链接的教程是有害的。 tldr;存储库使用实现UoW的DAO，但存储库不应该是UoW的一部分。除非你想使代码库/生活复杂化。

回答你的问题：

在您使用EF或任何其他ORM后，UoW会自动在那里实施。如果你去micro-ORM路径（没有正当理由直接使用ado.net），UoW基本上就是db事务。存储库应始终处理应用程序对象，从不与ORM（持久性）对象。如果您的应用程序对象用作持久性实体，那么您可能拥有标准的CRUD应用程序，并且您并不真正需要存储库模式。对于简单的应用程序，直接使用ORM（它可以节省大量时间）。
Repository使用实现UoW的DAO作为实现细节。应用程序的其余部分不知道存储库（接口）本身之外的任何内容。
定义了存储库接口，使用它（通常是域/业务层）。存储库实现是DAL的一部分。请注意，您应该使用仅存储库来更改模型（创建/更新/删除）。对于查询，让query services (objects)处理特定用例并直接使用db更容易和可维护。

saa很多人滥用了存储库模式，我建议阅读我的"Repository for dummies"帖子，以了解这是一个非常简单的模式，与您复杂的例子无关。经常看到。

如何使用ADO.NET使用存储库和工作单元模式？

4 个答案: