为什么我应该在我的EF顶部构建一个具有工作单元的存储库模式？

Question

根据MSDN的DbSet:

DbSet<TEntity> Class

A DbSet represents the collection of all entities in the context,或者可以从数据库查询给定类型.DbSet对象是使用DbContext.Set方法从DbContext创建的.

---

并根据MSDN的DbContext:

DbContext Class

甲DbContext instance represents a combination of the Unit Of Work and Repository patterns,使得它可以用来从数据库和组查询然后将被写回到存储作为一个单元一起变化.DbContext在概念上类似于ObjectContext.

---

这样就可以EF使用repository pattern和UOW内部.

DbSet <---->存储库

DbContext <---->工作单位

为什么我要在EF的顶部构建一个包含工作单元的存储库模式？

Answer 1

为什么我应该在我的EF顶部构建一个具有工作单元的存储库模式？

取决于您希望如何管理依赖项.

如果Entity Framework是您的抽象层而数据库本身是依赖关系,那么Entity Framework确实已经提供了您的存储库和工作单元.权衡是您的域依赖于实体框架.只要这种依赖性是可以接受的,你就是好的.

另一方面,如果您希望将Entity Framework本身视为可以在不更改域代码的情况下进行交换的依赖项,那么您需要创建一个抽象作为包装器的包装器.

基本上,这一切都归结为你绘制什么是或不是"外部依赖"的线.对于某些项目来说无关紧要,对某些项目而言,它是物理数据库,对某些项目而言,它是数据访问框架等.

Answer 2

为什么我要在EF的顶部构建一个包含工作单元的存储库模式？

由于接口隔离原则.该方法签名DbSet并且DbContext基本上是一个大的低级别混乱,它们之间存在巨大的不匹配,并且通常在存储库和工作单元中预期的不匹配.换句话说,如果你使用DbSet和DbContext直接,你的应用程序服务代码将遭受漏抽象.

在Application层中,您需要操作适当的语义.该层中的代码只需要说明业务事务和大型集合,您可以在其中获取和存储内容.这些是非常高级,极简主义的抽象概念.实体框架术语过于模糊和低级别,因此您需要引入其他习语 - 存储库和UoW.