Advice on mapping of entities to domain objects [closed]

Question

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?

Answer 1

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.

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.

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.

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

Update (2015)

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>

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.

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.

Answer 2

Why don't you simply use EF entities as Domain objects since you are looking into using Entity Framework 6 code first? So first you design Domain Model then Data Base structure.

I've been using NHibernate and believe that in EF you can also specify mapping rules from DB tables to your POCO objects, especially with EF6. It is an extra effort to develop another abstraction layer over EF entities. Let ORM be responsible for it.

I do not agree with this article that you might read "Entity Framework 5 with AutoMapper and Repository Pattern" and there are many other articles where people simply use EF entities as Domain objects:

• Creating an Entity Framework Data Model for an ASP.NET MVC Application (1 of 10)
• SO question "Domain Driven Design and Entity Framework 4.1 (code-first)"
• Generic information about DDD "Domain Driven Design and Development In Practice"
• Entity Framework ‘Code First’ Approach and Domain-Driven Design

AutoMapper will definitely help you when you start building presentation layer and face lots of UI specific view models. It is useful in building anemic models and a bit useless with real Domain objects when there are no public setters.

There is an old post by Jimmy Bogard "The case for two-way mapping in AutoMapper" where he tells that "There is no two-way mapping because we never need two-way mapping."

So what are we using AutoMapper for? Our five profiles include:

• From Domain to ViewModel (strongly-typed view models for MVC)
• From Domain to EditModel (strongly-typed view models for forms in MVC)
• From EditModel to CommandMessages – going from the loosely-typed EditModel to strongly-typed, broken out messages. A single EditModel might generate a half-dozen messages.
• From Domain to ReportModel – strongly-typed Telerik reports
• From Domain to EDI Model – flattened models used to generate EDI reports