The case for two-way mapping in AutoMapper

One scenario where a two way mapping could be useful would be domain model to dto which gets passed through a web service and then dto to domain model. you may not necessarily want to pass the domain model thru the web service to reduce overhead, or due to serialization issues.

Gagan

to be more specific, its not necessarily a two way mapping, but rather a

source domain model to dto, this dto is exposed thru a web  service then dto to target domain model,,,, the source and target domain model need not necessarily be exactly the same.

I don't particularly mind two way mapping being separate, but with MS MVC I do have alot of EditModels that are converted from DomainModels (for edit forms) and back again (when save is pressed).

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #436

We have an "external" domain model generated from Web service data contract, but it doesn't fit our needs internally (for MVC), so we implemented our own. But we still need two-way mapping between those two models (for Web service's input and output parameters)

Thanks for this. We'd wanted to do mapping to Domain objects and created the very tension you are talking about. This helped clear up my thinking.

Hi Jimmy,

Have you blogged about how you convert the EditModel to CommandMessages before? I don't remember that, and a search for CommandMessages doesn't return anything.

I'd be very interested to learn a little more about some of the specifics, just to see how the alpha devs route information back from form to model (not viewmodel). Obviously I initially just thought you were creating the message to pass into the service layer to perform the form operation, the fact you said you may produce many commands though made me wonder if there was more to it?  

I suspect this is where you neatly sidestep any perceived requirement for 2 way mapping.

Loving all the automapper posts, great work :-)

I use Automapper one way only. Mostly used it when I am too lazy and need to copy one entity to another entity straight off but it would be extremely usefull for ASP.NET MVC as well. Never had any use for any two way copying.

We have a domain model that we map to DTO objects requested by the client application.  At the client layer these DTO objects are used to display/edit info.  When such a DTO is received at our backend service, we map it to a domain model again.  Sometimes straightforward mapping is not possible, sometimes it is.  That's when 2 way mapping comes into play.  How are you mapping incoming DTO to your domain model?

The need for two-way mapping comes from people doing basic data driven CRUD operations through their service layers. So instead of fixing the real problem of not doing so, they want AutoMapper to save them from the trouble of having to do the mapping manually. The fact that AutoMapper don't support this is a good thing, as it enforces a good design principle of not exposing CRUD. Those who still desperately want to do it, can already do so by just setting up the mapping each way separately anyway.

I believe Olsen is pretty accurate. People are designing their domain to be directly mapped to and from the presentation layer. I used to do that until I started looking into command messages and realized that this is the better way to go. Even if I did want to map to and from a presentation model, the mapping logic would be different in each direction.

I wouldn't even know how the AutoMapper API should be written to handle such a scenario. Before hitting this thread, I just set up the mapping each way separately.

Part of the documentation of AutoMapper should probably state the design patterns it is expected to be used within.

2-way mapping would be very handy for us here at HSI.  We have AutoMapper.CreateMap<AEntity,AContract> and then AutoMapper.CreateMap<AContract,AEntity> all over the place.

To answer your questions...

   *  What scenarios are you looking at doing two-way mapping?

Mapping DTOs to entities and then entities back to DTOs.  For one example, we have a workflow application that gets data from a web service (which comes from a DB by way of entities and NH).  The user can then make changes in the app, publish the contracts back to the web service (which puts them back in the DB by way of entities and NH).

   * What impact would two-way mapping have on the originating source type?

None.  For simple entities where the only sensible DTO shape looks exactly like the entity, 2-way mapping would be very handy.  (This is common.)  For more complex entities where the DTO would make more sense having a different shape than the entity, then you could have separate mappings for DTO -> Entity and Entity -> DTO to re-shape the data according to your needs.

   * How would you test two-way mappings?

Test the translation of a DTO to entity and then separately test the translation of an entity to a DTO (or what have you).

I'm interested in a practical example of what you mean about "not needing a two way binding".

This because if I think about mapping a Model POCO to a ViewModel then after MVC model binding, I want to remap some part of my ViewModel to a Model Object just because I use it as an input of our service methods, and I'm courios about how you have implemented what you said

Pingback from  ASP.NET MVC Archived Buzz, Page 1

Can someone explain further the concept of command messages and include a sample using automapper?  It might be helpful for those of us who do not understand the concepts behind it and why it might be useful over a DTO->entity mapping.

I'd like to put forward an argument for 2 way mapping... that might just illustrate my lack of ability to see the wood for the trees, but here goes:

Olsen, above, was indicating that performing CRUD throughout an application stack was a bad smell, but looking at REST based services, that can be what 80% of the functionality needs to do. However, its not straight CRUD... for instance, if a client does a GET on a resource, the representation they recieve probably won't be a straight serialisation of an entity object. You'll probably want to add some data (e.g. the resource's URI and URIs of related resources). YOu might want to hide some data (e.g. confidential data like total number of sales of a product). These all seem good reasons to have a DTO and to introduce AutoMapper.

But what about when the client PUT or POSTs the representation back... it will be in the same form that the DTO was served to them. So probably the simplest type to deserialise that representation into is the DTO that was used for the GET processing. What next in this "CRUD" process?

Without two way mapping it appears I have two choices:

1) Hand crank the code to retrieve the entity from the database and change some of its values to match those passed in by the client, the save. This seems a shame since I'm only doing the reverse of what AutoMapper did automatically for me (i.e. AutoMapper has been fantastic for half of my functionality). This could work for a simple service, but as the service has to support more representations of the same entity, the amount of code would really build up.

2) As suggested by other commentors, have two separate mappings Entity -> DTO and DTO -> Entity... but, hang on, the DTO -> Entity mapping won't pass validation because the DTO doesn't have enough properties to populate the entire Entity. Remember, the confidential data mentioned above is not available in the DTO.

Neither of these is satisfactory. My ideal would be a single Entity -> DTO mapping that was capable of merging a DTO back into an existing Entity (i.e. it only updated the fields in the Entity that the mapping was populating in the opposite direction).

So does this count as a viable reason? Or am I missing an obvious alternative?

Jimmy, I'd like to explore the Command Message route, but I haven't been able to find any blogs/articles about it.

The CodeCampServer and Tarantino RulesEngine are all I've been able to find - is this the best place to learn about the pattern? Any other guidance would be much appreciated.

Another benefit to using a CommandMessage is the ability to handle them asynchronously or treat them as events using an EventAggregator to allow different services to subscribe to them.

Thanks, good article. I'd been wondering why there wasn't any consideration for 2-way in AutoMapper but it makes sense now.