域驱动设计中的实体和实体框架是否应该相同? [英] Should Entities in Domain Driven Design and Entity Framework be the same?

问题描述

我第一次开始使用Entity Framework Code First，并且对围绕域而不是在关系数据库表周围构建我们的未开发应用程序的方式印象深刻(这就是我多年来的工作方式).

因此，我们正在用C#构建实体，每次执行新迁移时这些实体都会反映在数据库中.

我的问题是:这些相同的实体(即在设计时考虑了Entity Framework的实体)是否应与域驱动设计中的实体(即代表域的核心)发挥相同的作用?

解决方案

对象关系映射和域驱动设计是两个正交的问题.

ORM

ORM只是为了弥合数据库中驻留的关系数据模型与对象模型(任何对象模型)之间的鸿沟.

由EF定义的实体具体表示您希望将关系模型的某些子部分映射到(或从中映射)的任何对象.事实证明，EF创造者希望通过给它们命名实体来赋予那些商业含义，但最终没有任何东西强迫您这样做.您可以将其映射到查看模型".

DDD

从DDD的角度来看，没有诸如考虑到EF设计的实体"之类的东西. DDD实体应该是持久性无知的，并且不包含任何ORM的痕迹.域层对对象的存储方式，位置，是否或时间没有兴趣.

两个人见面的地方

两个正交概念相交的唯一点是，您的ORM映射所针对的对象模型恰好是您的域模型.通过EF称为代码优先"(但应真正命名为常规ORM)，这可以实现，方法是在非域层中的单独EF映射文件中指向DDD实体，并避免使用EF工件(例如数据注释)直接在您的Entity类中.使用Database First时，这是不可能的，因为无法满足交易中DDD的纯度"部分.

简而言之，这些术语相冲突，但是从概念上讲，它们实际上应该被认为是两个不同的事物.一个是域对象本身，另一个是可以指示同一堆代码的指针，但是它可以指向几乎所有其他内容.

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).

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

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.

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

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.

Where the two meet

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.

这篇关于域驱动设计中的实体和实体框架是否应该相同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！