我正在开始一个新项目，并决定尝试整合DDD模式，并将Linq包含在实体中。当我看到EF的ObjectContext，它似乎正在执行Repository和Work of Work模式的功能：
存储库在底层数据级接口从实体表示中抽象出来，我可以通过ObjectContext请求和保存数据。
工作单位，我可以将所有的插入/更新写入objectContext，并在执行SaveChanges()时一次性执行它们。
将这些模式的另一层放在EF ObjectContext之上似乎是多余的？也可以使用“部分类”将Model类直接并入EF生成的实体之上。
我是DDD的新人，所以请让我知道，如果我在这里遗漏的东西。
解决方法
我不认为实体框架是Repository的一个很好的实现，因为：
>对象上下文不足以抽象出来，对引用它的事物进行良好的单元测试，因为它绑定到数据库访问。拥有一个IRepository参考而不是更好地创建单元测试。
>当客户端访问ObjectContext时，客户端几乎可以做任何事情。你所拥有的唯一真正的控制就是使某些类型或属性是私有的。这样很难实现良好的数据安全。
>在一个非平凡的模型中，ObjectContext不够抽象。例如，您可以将表和存储过程映射到同一实体类型。你真的不希望客户端区分两个映射。
>在相关的说明中，很难编写全面且执行良好的业务规则和实体代码。的确，无论这是否是一个好主意都是有争议的。
另一方面，一旦有了ObjectContext，实现Repository模式是微不足道的。实际上，对于不是特别复杂的情况，Repository是ObjectContext和Entity类型的封装。
