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

发布时间：2020-12-14 21:44:41 所属栏目：资源来源：网络整理

导读：我正在开始一个新项目，并决定尝试整合DDD模式，并将Linq包含在实体中。当我看到EF的ObjectContext，它似乎正在执行Repository和Work of Work模式的功能：存储库在底层数据级接口从实体表示中抽象出来，我可以通过ObjectContext请求和保存数据。工作单位，

我正在开始一个新项目，并决定尝试整合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类型的封装。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!