实体框架6.0下的ORM实体与域实体 [英] 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代码使用Code First方法。我使用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.

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