实体框架作为存储库和UnitOfWork？

我正在开始一个新项目,并决定尝试合并DDD模式,还包括Linq to Entities.当我查看EF的ObjectContext时,它似乎正在执行Repository和Unit of Work模式的功能:

存储库的意思是底层数据级接口是从实体表示中抽象出来的,我可以通过ObjectContext请求和保存数据.

工作单元在某种意义上说,我可以写入对objectContext的所有插入/更新,并在执行SaveChanges()时一次性执行它们.

将这些模式的另一层放在EF ObjectContext之上似乎是多余的？似乎Model类可以使用'partial class'直接合并到EF生成的实体之上.

我是DDD的新手,所以如果我在这里遗漏了什么,请告诉我.

1> Craig Stuntz..：

---

我不认为实体框架是一个很好的Repository实现,因为:

对象上下文不够抽象,不能对引用它的事物进行良好的单元测试,因为它绑定到DB访问.相反,使用IRepository引用可以更好地创建单元测试.

当客户端可以访问ObjectContext时,客户端可以执行它关心的任何事情.对此完全唯一的真正控制是将某些类型或属性设为私有.以这种方式很难实现良好的数据安全性.

在一个非平凡的模型上,ObjectContext不够抽象.例如,您可以将表和存储过程映射到同一实体类型.您并不希望客户端必须区分这两个映射.

在相关的说明中,很难编写全面且执行良好的业务规则和实体代码.事实上,这是否是一个好主意,这是值得商榷的.

另一方面,一旦有了ObjectContext,实现Repository模式就很简单了.实际上,对于不是特别复杂的情况,Repository是ObjectContext和Entity类型的包装器.

---

谢谢克雷格.我在http://www.simonsegal.net/blog/2009/01/13/entity-framework-repository-specifications-and-fetching-strategies/的Simon Segal博客中发现了一些代码,它提供了一些示例Repository实现实体框架.

2> Frederik Ghe..：

---

我会说你应该把ObjectContext看作你的UnitOfWork,而不是作为一个存储库.

ObjectContext不能是一个存储库-imho-因为它是'泛型'.您应该创建自己的存储库,它们在常规CRUD方法旁边有专门的方法(例如GetCustomersWithGoldStatus).

所以,我要做的是创建存储库(每个聚合根一个),并让这些存储库使用ObjectContext.