Map complex DTO to Entity about cleanarchitecture HOT 2 CLOSED

I'm also interested in this question. But almost a year and no answer...

@malohr Did you find a solution to your question?

from cleanarchitecture.

Sorry for the over long delay in responding.

Short version: I agree with the referenced article.

Longer version:

1. If you have very simple crud, with no nested collections, you can just use DTOs and yes, even AutoMapper. You can probably even just use entities directly (again if the types have no relationships and if all you need is CRUD).
2. If you have to do custom stuff in your AutoMapper config beyond renaming a column or saying something is optional, you probably shouldn't be using AutoMapper for that task.
3. AutoMapper is often more useful to go from domain entities to DTO types than the other direction.
4. A lot of the pain involved in the examples that article outlines is related to the lack of using an Aggregate with proper encapsulation. If instead of mapping the child collection using AutoMapper and then worrying about deleted/updated collection items, the code in question should have been loading the aggregate and then calling methods on it to modify its state based on changes that had been made. Updates can just be made to the child items directly; adds and deletes should be made through the aggregate root which then is saved in its entirety.
5. If you're building a web app/API you may need to consider how you want to handle updates, in terms of chunky vs. chatty. You probably don't want to expose a separate API endpoint per property to update, but it may be helpful to know, when a DTO is offered, which properties the client is attempting to change. You probably don't want to try and save the state of every piece of the aggregate, every time, especially if there are domain events or other behaviors associated with them that would be fired even if it wasn't actually changed (or now you must add code to detect changes in these methods). In short, some thought should go into this scenario so that you can balance encapsulating your design with practical use of the external API by client code. And in any case you probably don't want to use AutoMapper for your updates and deletes. You might get away with it for Creates but even then I'd be careful.

from cleanarchitecture.