将工作单元和存储库模式与实体框架一起使用的好处答案

【问题标题】：Benefit of using Unit of Work and Repository Patterns with Entity Framework将工作单元和存储库模式与实体框架一起使用的好处
【发布时间】：2017-11-21 16:23:54
【问题描述】：

根据MSDN，DbContext定义为：

表示工作单元和存储库模式的组合并使您能够查询数据库并将更改组合在一起然后将作为一个单元写回商店。

既然DbContext 实现了工作单元和存储库模式，那么为什么这个ASP.NET tutorial 和我在Internet 上找到的其他资源演示了DbContext 与工作单元和存储库的自定义实现一起使用模式？这不是多余的吗？

如果不是，那么在使用DbContext 时创建工作单元和存储库层的自定义实现有什么好处？（我可以看到这在测试项目中是如何有意义的。）

【问题讨论】：

标签： .net asp.net-mvc entity-framework repository unit-of-work

【解决方案1】：

是的，DbContext 代表一个工作单元，DbSet 代表一个存储库，但是有些人会在它们之上创建一个抽象层。以下是人们可能会这样做的一些原因：

也许他们不希望他们的项目与实体框架及其架构紧密耦合。因此，他们将实体框架隐藏在这些抽象背后，以便他们可以用实体框架替换任何其他 ORM，而无需对数据访问层的接口进行任何修改。
他们使用存储库来明确允许某些实体执行哪些操作。 （例如，CustomerRepository 可能允许添加和更新客户，但不能删除他们）。另一方面，它使客户端开发人员能够轻松识别某些实体的可用操作。换句话说，他们创建的存储库具有与领域语言兼容的命名约定和接口。
将与数据库相关的操作移至存储库允许您拦截这些操作并执行日志记录、性能调整或任何其他您想要的操作。
有些人这样做是为了使测试更容易。假设我有一个带有三种方法的ICustomerRepository 接口。然后我可以轻松地模拟它，而不是用太多方法模拟 IDbSet<Customer>。
最后，有很多人不在DbContext 和DbSet 上创建抽象。他们只是直接使用它们，这样做是完全有效的。

【讨论】：

【解决方案2】：

我知道为时已晚

对于工作单元：当您将数据导入和导出数据库时，跟踪您所做的更改很重要。同样，您必须插入新的对象创建和删除您删除的任何对象。

您可以在每次更改对象模型时更改数据库，但这会导致大量非常小的数据库调用。

工作单元会跟踪您在业务交易期间所做的所有可能影响数据库的操作。

对于存储库模式：它是一个与数据库隔离的业务域。

阅读本书 (PEAA)

【讨论】：

PEAA 已过时。模式实现在当今的标准中很糟糕（显式线程本地存储、域对象内与工作单元相关的代码等）。因此，人们可能只是从书中获取模式列表，而忽略任何示例实现。