ORM 实体与实体框架 6.0 下的域实体 [英] ORM Entities vs. Domain Entities under Entity Framework 6.0

问题描述

我偶然发现了以下两篇文章 首先 和 第二，其中作者总结说 ORM 实体和领域实体不应该混淆.

I stumbled upon the following two articles First and Second in which the author states in summary that ORM Entities and Domain Entities shouldn't be mixed up.

当我使用代码优先方法使用 EF 6.0 进行编码时，我目前正面临这个问题.我使用 POCO 类作为 EF 中的实体以及我的域/业务对象.但我发现自己经常处于将属性定义为公共属性或将导航属性定义为虚拟的情况，这仅仅是因为 EF 框架强迫我这样做.

I face exactly this problem at the moment as I code with EF 6.0 using the Code First approach. I use the POCO classes as entities in the EF as well as my domain/business objects. But I find myself frequently in the situation where I define a property as public or a navigation property as virtual only because the EF Framework forces me to do so.

我不知道这两篇文章的底线是什么?我真的应该为实体框架创建一个 CustomerEF 类，为我的域创建一个 CustomerD 类吗?然后创建一个使用 CustomerD 的存储库，将它映射到 CustomerEF 做一些查询，然后将接收到的 CustomerEF 映射回 CustomerD.我认为 EF 就是将我的域实体映射到数据.

I don't know what to take as the bottom line of the two articles? Should I really create for example a CustomerEF class for the entity framework and a CustomerD for my domain. Then create a repository which consumes CustomerD maps it to CustomerEF do some queries and than maps back the received CustomerEF to CustomerD. I thought EF is all about mapping my domain entities to the data.

所以请给我一些建议.我是否忽略了 EF 能够为我提供的重要内容?或者这是EF无法完全解决的问题?在后一种情况下，管理此问题的好方法是什么?

So please give me some advice. Do I overlook an important thing the EF is able to provide me with? Or is this a problem which can not completely solved by the EF? In the latter case what is a good way to manage this problem?

推荐答案

我同意这些帖子的总体思路.ORM 类模型首先是数据访问层的一部分(即使它由所谓的 POCO 组成).如果持久性和业务逻辑(或任何其他问题)之间出现任何利益冲突，则应始终做出有利于持久性的决策.

I agree with the general idea of these posts. An ORM class model is part of a data access layer first and foremost (even if it consists of so-called POCOs). If any conflict of interests arises between persistence and business logic (or any other concern), decisions should always be made in favor of persistence.

然而，作为软件开发人员，我们总是必须在纯粹主义和实用主义之间取得平衡.是否将持久性模型用作域模型取决于多种因素:

However, as software developers we always have to balance between purism and pragmatism. Whether or not to use the persistence model as a domain model depends on a number of factors:

• 开发团队的规模/一致性.当整个团队都知道仅仅因为 ORM 要求属性可以公开，但不应该到处设置时，这可能没什么大不了的.如果每个人都知道(并遵守)在业务逻辑中不使用 ID 属性，那么拥有 ID 可能不是什么大问题.一个分散、缺乏经验或缺乏纪律的团队可能需要更严格的代码隔离.

• The size/coherence of the development team. When the whole team knows that properties can be public just because of ORM requirements, but should not be set all over the place, it may not be a big deal. If everybody knows (and obeys) that an ID property is not to be used in business logic, having IDs may not be a big deal. A scattered, unexperienced or undisciplined team may need more stringent segregation of code.

业务逻辑关注点和持久性关注点之间的重叠.当类模型坚持 SOLID 原则时，面向对象的设计会蓬勃发展.但这些原则不一定与持久性问题相悖.我的意思是，尽管关注点不同，但最终它们的最终要求可能非常相似.例如，这两个问题都可能需要有效的对象状态和正确的关联.

The overlap between business logic concerns and persistence concerns. Object oriented design thrives when a class model sticks to SOLID principles. But these principles are not necessarily at odds with persistence concerns. I mean that although the concerns are different, in the end their resultant requirements may be quite similar. For instance, both concerns may require valid object state and correct associations.

但是，可能存在一些用例，其中对象暂时需要处于绝对不应存储的状态.这可能是使用专用域类的原因.另一个原因可能是实体模型无法实现最佳的职责划分.例如，业务流程将客户列入黑名单"可能需要分散在许多实体对象上的数据，因此必须设计新的域类来封装数据和处理它们的方法.换句话说:实体这样做会违反告诉不要问原则.

There can be use cases, however, in which objects temporarily need to be in a state that absolutely shouldn't be stored. This may be a reason to work with dedicated domain classes. Another reason may be that the entity model just can't fulfill the best segmentation of responsibilities. For instance, a business process "blacklisting customer" may require data that is scattered over so many entity objects that new domain classes must be designed that can encapsulate the data and the methods working on them. In other words: doing this by entities would violate the Tell Don't Ask principle.

需要分层.例如，如果数据访问层针对不同的数据库供应商，它可能必须由供应商特定的可互换部分组成(例如，为了解决 Oracle 和 Sql Server 之间数据类型的细微差异或利用供应商特定的功能).使用持久性模型作为域模型可能会将特定于供应商的实现渗透到业务逻辑中.那真的很糟糕.那里的数据访问层应该就是那个层.

The need for layering. For instance, if the data access layer targets different database vendors it may have to consist of interchangeable parts that are vendor-specific (e.g. to account for subtle differences in data types between Oracle and Sql Server or to exploit vendor-specific features). Using the persistence model as domain model would probably bleed vendor-specific implementations into the business logic. That would be really bad. There the data access layer should be precisely that, a layer.

(非常琐碎)数据量.创建对象需要时间和资源.当许多"业务案例中涉及到的对象可能只是构建实体对象和域对象的成本都太高了.

(Very trivial) The amount of data. Creating objects takes time and resources. When "many" objects are involved in a business case it may just be too expensive to build both entity objects and domain objects.

毫无疑问，还有更多.

所以我会一直努力成为一个实用主义者.如果实体类做得不错，那就去做吧.如果不匹配太大，请为业务逻辑的适当部分创建业务域.我不会仅仅因为它是一个好的模式就盲目地遵循(任何)设计模式.与帖子中所说的相反，将实体模型映射到业务模型需要大量维护.当您发现自己创建了无数与实体类几乎相同的业务类时，是时候重新思考您在做什么了.

So I would always try to be a pragmatist. If entity classes do a decent job, go for it. If the mismatch is too large, create a business domain for appropriate parts of the business logic. I would not slavishly follow a (any) design pattern just because it is a good pattern. Contrary to what is said in the post, it requires a lot of maintenance to map an entity model onto a business model. When you find yourself creating myriads of business classes that are almost identical to entity classes it's time to rethink what you're doing.

这篇关于ORM 实体与实体框架 6.0 下的域实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！