Is there a way to do hierarchical mapping like GraphDiff ?

[MilanRaval]

Entity Relations:

GraphDiff allows to map it like....

context.UpdateGraph(application, map => map
   .OwnedEntity(cf => ap.Customer, with => with
       .OwnedCollection(h => h.Contacts))

How to do same hierarchical mapping with DM Fluent API mapping ?
Does below DM mapping equal to the above GraphDiff mapping, both will generate same SQL updates queries when SaveChanges() are called ?

builder.UseMapping(mappingOptions => {

    mappingOptions.Default(profileOptions => {

        profileOptions.Type<Application>()
        .Member(c => c.Customers).Composition();

        profileOptions.Type<Customer>()
        .Member(c => c.Contacts).Composition();
    });
});

[leonardoporro]

Yes..
Lets say that you have this persisted in your DB:
application: { id: 1, customers: [ { id: 1 }, { id: 2 } ] }
and then, map this on it:
application: { id: 1, customers: [ { id: 1 } ] }
Since customer is marked as [Composition] or .Composition(), Customer Id: 2 will be deleted from the DB.

There are some differences with GraphDiff here:

1 - this library allows to map anything to the Customer entity, it could be the same entity, or CustomerDTO or a dictionary or even json.
2 - this library generates static mappers in runtime, so it doesn't allow to specify the map tree in the Map() call as GraphDiff does...
That is mainly because at mapping time, the tree (most of it) is already resolved to improve performance. However you can create different profiles for the same entity.
3 - this library aims to use DTO to Entity mapping and avoid Entity to Entity (check this.
Usually, we start an application with a couple of CRUDs. At that point, creating Commands or DTOs seems overkilling because they mostly have the same properties and you feel that you are repeating yourself.
As the application becomes more complex you'll find a lot of cases where passing Entities to endpoints just doesn't work, Maybe because you see Password field in your GET /users endpoint... or other unneded fields like IsDeleted (logical delete) or CreationDate, etc.
At this point we start addind DTOs and find that the ammount of code needed to map them to an entity is huge and we go for AutoMapper, TinyMapper or something similar. And after that we still need to deal with re-attaching entities issues.
The library tries to fill some gaps and make all of this easier for small-medium systems.
And the best way to avoid a field being mapped it's just by not adding it to the DTO. If it doesn't exist, it won't get mapped :)

There are more info about it here

Thanks for reading, I'd appreciate your input