So why is the Update Command not using Automapper

[jbennink]

I was working through my own code and converting to the IMapFrom interface when I noticed this. In the UpdateTodoItemCommand you use handcrafted a=b mappings.

CleanArchitecture/src/Application/TodoItems/Commands/UpdateTodoItem/UpdateTodoItemCommand.cs

Line 37 in d0f133e

entity.Title = request.Title;

I tried to fix this in my own code, but when using the IMapFrom interface this would require IMapFrom in the Domain project that has no project references, and referencing Application would be wrong.

I previously had a custom MappingProfile method in the Application project that would setup all mappings. Here I can create a Map from the Application object to a Domain object. But you cannot do this using the IMapFrom interface?

Is this a limitation of the IMapFrom (definied in Application) or am I doing something wrong to require a mapping from an Application object to a Domain object [I use this to map the Command objects inside the Handler methods to the corresponding Domain object) Or are we supposed to use two different mapping setups

[jbennink]

Since you add an IMapFrom to map the object from the T wuold it be OK to also include a mapping to the reverse in the Mapping method on the from object!

public class ApplicationCommand : IRequest<DomainObject>, IMapFrom<DomainObject>
{
public void Mapping(Profile profile) 
{
profile.CreateMap<DomainObject, ApplicationCommand>();
profile.CreateMap<ApplicationCommand, DomainObject>();
}

}

Now I do have both sides and this code resides in Application. But is the obsious/expressive enough since the interface is named explicitly IMapFrom . In my case there are some ForMember custom mappings in there as well otherwise I would not need to have this expliciet Mapping method.

[jbennink]

Or is it bad design to use automapper to map between Commands and domain objects?

[neman]

You should never use direct mapping to domain entities. You will lose invariants and encapsulation.

[summer600]

invariants and encapsulation.

But Application is already referencing Domain. And Automapper creates a dynamic map from properties between two types so what is the concern when I map my Mediatr UpdateTodoItemCommand to TodoItem domain object.

What is the "lose invariants and encapsulation" mean, what is the concern?

I mean UpdateTodoItemCommand and TodoItem are pretty much "related" If I want to add or change fields to TodoItem, I will need to update almost alle Commands to do with storing TodoItem, ie. The field has to be added in CreateTodoItem, UpdateTodoItem and probably even DeleteTodoItem. And vice versa most of the times adding stuff to the Command's will require changes to TodoItem. And even when they don't this will not break the dynamic mapping that automapper creates. It might break code, but that will also happen when I add fields to TodoItem and I forget to update the manually added mappings as described in my reference to the source.
I would say most of the time those mappings can be created by automapper and hence will result in fewer mistakes.

I am not a TDD of design based developer so I am trying to understand the reasoning behind not using automapper for some stuff where it seems it could be used?

[MichaelHochriegl]

I too don't quite understand why AutoMapper is not used. I kinda have been using the same structure as Jasons template in past, but I always used AutoMapper for query and command mapping as well.

If someone could give some detailed insight in why this is bad I would very much appreciate it.

[neman]

I already wrote a short version why not to do this. If you want, a more detailed version, then you should read some books and understand basic principles of OOP.

• Object Thinking, David West.
• Object-oriented analysis and design with applications, Booch Grady
• Design Patterns, GoF
• Object-Oriented Software Engineering: A Use Case-Driven Approach, Jacobson Ivar
• Domain Driven Design, Eric Evans
• All of Martin Fowler books and bliki entries
• etc

Or you could just read couple of blog posts, and see what does the creator of automapper have to say about this topic:

https://lostechies.com/jimmybogard/2009/09/18/the-case-for-two-way-mapping-in-automapper/

https://enterprisecraftsmanship.com/posts/on-automappers/

You should read at least these two blogs. But if you want to become a better craftsman, you should also read above books.

Software development is not just googling and copy pasting working code from stackoverflow. I do not say It is a bad thing per se, but you should always give meaning to your code and have review of what you are doing.

[summer600]

I thought I already replied, but seem to have forgotten.

@neman The short version you wrote on may 10th simply states you should not do it. The two words used to explain why are not really helpful. The list of books are also very broad, you might as well have said "learn to program" they do nothing to explain. Unless there is no concise explanation possible it feels like I am not supposed to do it because everyone important says so.

I really want to understand what I might loose here. And if the answer is, for a simple system you won't lose anything because you simply won't have the complexity to get in to trouble even when you program it very badly that is fine too. I don't want to use techniques that are overkill, but I do like readable code and automapper seems to deliver that, eventhough it seems you duplicate a lot of properties between viewmodels, command objects and domain entities.

I was actually hoping @jasontaylordev might shed some light on why this template does still have handcrafted object mappings and what the benefits of that are over using automapper to create these mappings.