实体框架作为存储库和UnitOfWork？ [英] Entity Framework as Repository and UnitOfWork?

问题描述

我正在开始一个新项目，并决定尝试合并DDD模式，并将Linq包含在实体中。当我查看EF的ObjectContext时，似乎正在执行存储库模式和工作单元模式的功能：通过实体表示，我可以通过ObjectContext请求并保存数据。

工作单元，因为我可以将所有插入/更新写入objectContext并执行当我执行SaveChanges（）时，它们全部合而为一。

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

我是DDD的新手，所以如果我在这里缺少东西，请告诉我。

解决方案

我认为实体框架不是存储库的良好实现，因为：

• 对象上下文不够抽象，无法对引用它的事物进行良好的单元测试，因为它绑定到数据库访问。相反，使用IRepository引用可以更好地创建单元测试。


• 当客户端可以访问ObjectContext时，客户端可以执行其所需的几乎所有操作。您对此的唯一真正控制权是将某些类型或属性设为私有。这样很难实现良好的数据安全性。


• 在一个简单的模型上，ObjectContext不够抽象。例如，您可能将表和存储过程都映射到相同的实体类型。您并不是真的希望客户不必在两个映射之间进行区分。


• 在相关说明中，很难编写全面而有效的业务规则和实体代码。的确，这是否一个好主意还值得商.。

另一方面，一旦有了ObjectContext，实现存储库模式就很简单了。确实，对于不是特别复杂的情况，存储库是ObjectContext和Entity类型的包装。

I'm starting a new project and have decided to try to incorporate DDD patterns and also include Linq to Entities. When I look at the EF's ObjectContext it seems to be performing the functions of both Repository and Unit of Work patterns:

Repository in the sense that the underlying data level interface is abstracted from the entity representation and I can request and save data through the ObjectContext.

Unit Of Work in the sense that I can write all my inserts/updates to the objectContext and execute them all in one shot when I do a SaveChanges().

It seems redundant to put another layer of these patterns on top of the EF ObjectContext? It also seems that the Model classes can be incorporated directly on top of the EF generated entities using 'partial class'.

I'm new at DDD so please let me know if I'm missing something here.

解决方案

I don't think that the Entity Framework is a good implementation of Repository, because:

• The object context is insufficiently abstract to do good unit testing of things which reference it, since it is bound to the DB access. Having an IRepository reference instead works much better for creating unit tests.
• When a client has access to the ObjectContext, the client can do pretty much anything it cares to. The only real control you have over this at all is to make certain types or properties private. It is hard to implement good data security this way.
• On a non-trivial model, the ObjectContext is insufficiently abstract. You may, for example, have both tables and stored procedures mapped to the same entity type. You don't really want the client to have to distinguish between the two mappings.
• On a related note, it is difficult to write comprehensive and well-enforce business rules and entity code. Indeed, whether or not it this is even a good idea is debatable.

On the other hand, once you have an ObjectContext, implementing the Repository pattern is trivial. Indeed, for cases that are not particularly complex, the Repository is something of a wrapper around the ObjectContext and the Entity types.

这篇关于实体框架作为存储库和UnitOfWork？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！