Best Practices For Mapping DTO to Domain Object?

Question

I\'ve seen a lot of questions related to mapping DTOs to Domain Objects, but I didn\'t feel they answered my question. I\'ve used many methods before and have my own opinio

Answer 1

I can suggest a tool I created and is open source hosted at CodePlex: EntitiesToDTOs.

Mapping from DTO to Entity and vice-versa is implemented by extension methods, these compose the Assembler side of each end.

You end with code like:

Foo entity = new Foo();
FooDTO dto = entity.ToDTO();
entity = dto.ToEntity();

List<Foo> entityList = new List<Foo>();
List<FooDTO> dtoList = entityList.ToDTOs();
entityList = dtoList.ToEntities();

Answer 2

Keeping the mapping logic inside of your entity means that your Domain Object is now aware of an "implementation detail" that it doesn't need to know about. Generally, a DTO is your gateway to the outside world (either from an incoming request or via a read from an external service/database). Since the entity is part of your Business Logic, it's probably best to keep those details outside of the entity.

Keeping the mapping somewhere else would be the only alternative - but where should it go? I've tried introducing mapping objects/services but, after all was said and done, it seemed like overengineering (and probably was). I've had some success using Automapper and such for smaller projects but tools like Automapper come with their own pitfalls. I've had some pretty hard to find issues related to mappings because Automapper's mappings are implicit and completely decoupled from the rest of your code (not like "separation of concerns" but more like a "where does the godforsaken mapping live") so they can sometimes be hard to track down. Not to say that Automapper doesn't have its uses, because it does. I just think mapping should be something that is as obvious and transparent as possible to avoid issues.

Instead of creating a mapping service layer, I've had a lot of success keeping my mappings inside of my DTOs. Since DTOs always sit at the boundary of the application, they can be made aware of the Business Object and figure out how to map from/to them. Even when the number of mappings scale to a reasonable amount it works cleanly. All the mappings are in one place and you don't have to manage a bunch of mapping services inside your Data Layer, Anticorruption Layer, or Presentation Layer. Instead, the mapping is just an implementation detail delegated to the DTO involved with the request/response. Since serializers generally only serialize properties and fields when you're sending it across the wire, you shouldn't run into any issues. Personally, I've found this the cleanest option and I can say, in my experience, it scales well on a large code base.

Answer 3

Another option would be to use ModelProjector. It supports all possible scenarios and is very easy to use with minimal footprint.

Answer 4

You can also try Otis, an Object-to-object mapper. Concepts are similar to NHibernate mapping (attribute or XML).

http://code.google.com/p/otis-lib/wiki/GettingStarted

Answer 5

We use T4 templates to create the mapping classes.

Pro's - human readable code available at compile time, faster than a runtime mapper. 100% control over the code (can use partial methods/template pattern to extend functionality on an ad-hoc basis)

Con's - excluding certain properties, collections of domain objects etc., learning T4 syntax.