问题描述
我第一次开始使用 Entity Framework Code First，对我们围绕域而非关系数据库表(这是我多年来一直工作的方式)构建的新应用程序的方式印象深刻.
I have started using Entity Framework Code First for the first time and am impressed by the way in which our greenfield application is being built around the domain rather than around the relational database tables (which is how I have worked for years).
因此，我们在 C# 中构建实体，每次执行新迁移时都会反映在数据库中.
So, we are building entities in C# that are being reflected in the database every time we do a new migration.
我的问题是:这些相同的实体(即在设计时考虑到实体框架)是否应该与域驱动设计中的实体(即代表域的核心)扮演相同的角色?
My question is this: should these same entities (i.e. designed with Entity Framework in mind) play the same role as entities in Domain Driven Design (i.e. representing the core of the domain)?
推荐答案
对象关系映射和领域驱动设计是两个正交的关注点.
Object-Relational Mapping and Domain-Driven Design are two orthogonal concerns.
ORM
ORM 只是为了弥合驻留在数据库中的关系数据模型和对象模型(任何对象模型)之间的差距.
An ORM is just here to bridge the gap between the relational data model residing in your database and an object model, any object model.
EF 定义的实体具体意味着任何对象，您希望将关系模型的某些子部分映射到(和从).事实证明，EF 的创建者希望通过命名实体来赋予这些实体以商业内涵，但最终没有什么能强迫您这样做.您可以映射到 View Models 以解决所有问题.
An Entity as defined by EF concretely means any object that you wish to map some subpart of your relational model to (and from). It turns out that the EF creators wanted to give a business connotation to those by naming them Entities, but in the end nothing forces you that way. You could map to View Models for all it cares.
DDD
从 DDD 的角度来看，不存在设计时考虑到 EF 的实体"这样的东西.一个 DDD 实体应该是持久性无知的，并且没有任何 ORM 的痕迹.领域层对其对象的存储方式、位置、是否或何时存储不感兴趣.
From a DDD perspective, there's no such thing as "an Entity designed with EF in mind". A DDD Entity should be persistence ignorant and bear no trace of any ORM. The domain layer has no interest in how, where, whether or when its objects are stored.
两人相遇的地方
这两个正交概念的唯一交叉点是您的 ORM 映射所针对的对象模型正是您的领域模型.这可以通过 EF 所谓的代码优先"(但实际上应该命名为常规 ORM)来实现，方法是在位于非域层的单独 EF 映射文件中指向您的 DDD 实体，并避免使用 EF 工件，例如数据注释直接在您的实体类中.这在使用 Database First 时是不可能的，因为交易的 DDD纯度"部分不会得到满足.
The only point where the two orthogonal concepts intersect is when the object model targeted by your ORM mapping is precisely your domain model. This is possible with what EF calls "Code first" (but should really be named regular ORM), by pointing to your DDD Entities in separate EF mapping files living in a non-domain layer, and refraining from using EF artifacts such as data annotations directly in your Entity classes. This is not possible when using Database First, because the DDD "purity" part of the deal wouldn't be met.
简而言之，这两个术语是有冲突的，但它们实际上应该在概念上被视为两种不同的事物.一个是域对象本身，另一个是可以指示同一组代码的指针，但它几乎可以指向任何其他内容.
In short, the terms collide, but they should really be conceptually considered as two different things. One is the domain object itself and the other is a pointer that can indicate the same bunch of code, but it could point to pretty much anything else.
这篇关于领域驱动设计和实体框架中的实体应该相同吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！