在实体映射域对象的意见 [英] Advice on mapping of entities to domain objects

问题描述

我目前在我们开始建立使用DDD方法的应用程序的项目工作。现在我们正在研究使用实体框架6代码首先，以帮助我们的数据持久化。我的问题是如何最好地处理我们的领域对象和EF实体之间的数据映射？

I'm currently working in a project where we are starting to build an application using a DDD approach. We are now looking into using Entity Framework 6 code first to help us with data persistence. My question is how to best handle data mapping between our domain objects and EF entities?

推荐答案

要保持你的应用程序和你自己理智长远，从此再也具有持久性相关的问题开始你的DDD应用（即DB什么ORM等），总是（是的，总是）触摸DB作为开发的最后阶段。

To keep your app and yourself sane on the long term, NEVER EVER start your DDD app with persistence related issues (what db, what orm etc) and ALWAYS (yes, always) touch the db as the last stage of the development.

建模您的域名，实际上，除了持久任何其他模式。使用Repository模式，以保持与持久性分离的应用程序。根据需要由应用程序，不依赖于数据库访问方法（这就是为什么你后来实现持久性，所以你不会受到诱惑耦合您的应用程序持久性细节）定义回购接口。

Model your Domain and in fact any other model except persistence. Use the Repository pattern to keep the app decoupled from the Persistence. Define the repo interface as needed by the app and not tied to the db access method (that's why you're implementing the persistence later so you won't get tempted to couple your app to persistence details).

将在内存中实现的回购接口，这通常意味着在一个列表或字典一个简单的包装因此它非常快速编写，更重要的是微不足道的改变。使用这些实际测试和开发应用程序。

Write in-memory implementations for the repo interfaces, this usually means a simple wrapper over a list or dictionary so it's VERY fast to write and more importantly trivial to change. Use those to actually test and develop the app.

在接口稳定和应用程序的工作原理那么它的时间来写持久化实现，你可以使用任何你想。你的情况EF和那里来的映射。

After the interfaces are stable and the app works then it's time to write the persistence implementation where you can use whatever you wish. In your case EF and there it comes the mapping.

现在，这是非常主观的存在不正确的或错误的方式，还有你喜欢做的事情的方式。

Now, this is highly subjective there isn't a right or wrong way, there's the way YOU prefer doing things.

就个人而言，我一直在使用的纪念品，所以我得到从域对象的纪念品，然后手动将其映射到（微）ORM实体的习惯。我做手工的原因是因为我的纪念品包含的值对象。如果我将使用AutoMapper我会需要到confingure它在本质上我不是做手工要写更多的代码

Personally, I have the habit of using mementos so I get the memento from the domain object and then manually mapping it to the (micro)ORM entities. The reason I'm doing it manually is because my mementos contain value objects. If I would be using AutoMapper I'd be needing to confingure it and in essence I'd be writing more code than doing it manually

更新（2015）

这几天我刚刚的Json对象，要么使用一个特定的读取模型或直接用数据读取模式存储它包含序列化对象列。我用的纪念品仅用于非常特殊的情况。 < /更新>

These days I just Json the object and either use a specific read model or store it directly in a read model with a Data column that contains the serialized object. I use Mementos only for very specific cases. < /update>

根据您的域对象的外观和EF实体如何看待你可能会使用automapper为广大的映射脱身。您将有困难时期，虽然测试你的存储库。

Depending on how your domain objects look and how the EF entities look you might get away with using automapper for the majority of the mapping. You will have a harder time testing your repositories though.

这是给您如何你做它，找到它的方式适合你的风格和它易于维护的但永远都不要设计或修改你的域对象更加兼容，或以匹配ORM实体。这不是改变数据库或奥姆斯，它是关于具有域（以及应用程序的其余部分）从持久性细节正确地去耦（其中ORM的）。

It's up to you how you do it, find the way it suits your style and it's easily maintainable but NEVER EVER design or modify your domain objects to be more compatible or to match the ORM entities. It's not about changing databases or ORMs, it's about having the Domain (and the rest of the app) properly decoupled from the Persistence details (which the ORM is).

所以，抵制诱惑，重用东西是其他层的实施细则。应用程序在层结构的原因是因为你想脱钩。保持这种方式。

So resist the temptation to reuse things which are other layers' implementation details. The reason the application is structured in layers is because you want decoupling. Keep it that way.

这篇关于在实体映射域对象的意见的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！