Please see the article here: http://enterprisecraftsmanship.com/2017/02/16/on-automappers/

The writer advises against using Automapper to map DTOs to domain objects as it can cause problems with validation. Why is this? My domain models have a function called Validate(), which is called by the Service Layer i.e. it has to be called explicitly by the service layer (and by the domain layer to make sure that the service layer has done its job. It is similar to how the same writer recommends validation in this article: http://enterprisecraftsmanship.com/2016/09/13/validation-and-ddd/ (see IsValid() method).

How does Automapper bypass validation if it is used to map DTOs to Domain Objects?

  • Not a C# dev, but my understanding of AutoMapper is that it uses reflection? Which is I think what the author is referring to when he says that it breaks encapsulation — if you are using reflection, you're not 'coming in through the front door' & making sure you create objects via their constructors, so therefore you may be breaking invariants of a class – anotherdave Aug 20 '17 at 17:19
  • See: devtrends.co.uk/blog/… – NoChance Aug 20 '17 at 18:05
  • @anotherdave, so if the validation is not in the constructor, then there is no problem. Is that right? – w0051977 Aug 21 '17 at 6:51
  • @NoChance, that link just explains how to use automapper in data access code. It has nothing to do with my question from what I can see. – w0051977 Aug 21 '17 at 6:53
  • It says: "Why can't we just use AutoMapper? ...when in comes to data access code, AutoMapper is not so useful. To put it simply, AutoMapper only works with in-memory data, not the IQueryable interface which is more typically used in DAL scenarios..." – NoChance Aug 21 '17 at 15:24

From what I gather, his point is that domain objects will not generally map 1-to-1 to the DTOs, in the sense that they will not have all the same properties. In fact, domain objects may have very few getters and setters; they may even have none at all. This is related to the the "tell, don't ask" principle: if responsibilities are properly distributed across classes, domain objects will have very little need to pull data from each other in order to achieve something. Instead, they will mostly call methods on each other. Now, while you can use Automapper-like libraries to copy data from DTOs to the domain objects in such a scenario, the author's point is that this requires a fairly complicated setup, which defeats the purpose of having an automapper.

They can perform the mapping of course, but that would require setting up quite sophisticated mapping rules which diminishes the value of having the automapper in the first place.

If the design of your domain objects is influenced by the desire to support easy automapping, then you'll break encapsulation by introducing getters and setters that are not really needed. This could introduce problems with validation. E.g., without automapping considerations, your domain objects may be designed in such a way so that it is not possible to invoke a method or a property and have the object end up in an invalid state when the control returns to the caller. If you introduce getters and setters and a Validate() method, then it becomes possible for an object to be in an invalid state between the a call to a setter, and a call to Validate(). That may or may not be OK - as everything else, it's a trade-off.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.