c# - EF5 中的 UOW 和存储库模式

Question

这是关于我对从这里找到的一些 Entity Framework Material 的一些困惑: https://www.asp.net/

在此页面上，它解释了如何使用存储库包装 dbcontext 以及如何使用工作单元类包装存储库: http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

然而，在此页面上它指出 dbcontext 已经是 UOW 模式和存储库模式的组合: https://msdn.microsoft.com/en-us/library/system.data.entity.dbcontext(v=vs.103).aspx

因此，如果这些模式解决的问题已经由 dbcontext 解决，为什么要使用 EF5 重新实现这些模式？

此外，在教程中，UnitOfWork 类似乎没有显示 UOW 应该提供的任何好处。例如，它指出:“这样，当一个工作单元完成时，您可以在该上下文实例上调用 SaveChanges 方法，并确保所有相关更改都将得到协调。”

但它似乎所做的只是无缘无故地包装 dbcontext。我想我错过了什么。我在这个实现中没有看到任何协调......如果出现问题，如何“回滚”？

Answer 1

不要使用另一个 UoW/存储库抽象层

正如 OP 正确指出的那样，Entity Framework(类似于 NHibernate 和其他 ORM)已经为您提供了一个数据库的抽象，其中包含您可用的事务性“工作单元”和“存储库”。

额外的 UoW/存储库抽象层是一个反模式，应该不惜一切代价避免。它有很多问题，其中最重要的是:

• 它们会阻止您使用底层 ORM 的全部功能(惰性加载、急切加载、复杂查询......)
• 如果他们想提供除简单 CRUD 之外的任何额外好处，它们将是有漏洞的(即反射(reflect)底层 ORM 中存在的功能)。

但是，但是，但是......

I need to be able to unit test by mocking my repositories

不，你不知道。只需使用包含特定于您的测试的内容的数据库即可。如果您希望速度更快，请使用内存数据库(例如 SQLite、Effort ……)。

EF does not enforce business logic which is not expressed in data relationships ... To enforce this type of logic, you have to build a OUW/Repository/both of some sort around the EF context.

不，你不应该。在基础结构抽象层(例如工作单元或存储库)中实现您的业务逻辑是完全错误的。

• 有值(value)的业务逻辑属于域实体、域服务、域命令或长期运行的业务流程、sagas。
• 简单验证(即不是null，x 和y 之间的值)不要:这些应该在您的系统接口(interface)边界解决.

另请注意，没有任何有值(value)的业务逻辑的简单 CRUD 样式操作不需要遍历所有“层环”，即避免这种模式:

1. 数据库 → 没有行为的实体 → DTO → View 模型 → View
2. 编辑字段
3. View → 查看模型 → DTO → 没有行为的实体 → 数据库

只需在 View 所需的“ View 模型”形状中直接从 Controller 中的 ORM 加载它，然后直接从 Controller 中保存它。

关于抽象

诸如此类的不必要的抽象和层环是有害的。它们混淆了您的代码，束缚了您的手脚，泄漏，增加了您的代码大小，因此增加了代码中的错误数量，却没有提供任何附加值。

当抽象为您提供附加值时使用抽象，例如当您需要它们来解决横切关注点、捕获/管理架构中重复出现的模式时，......

为了抽象而创建抽象是浪费时间。