Expose ResultExpressionList by given src and dest Types

[shay1e]

When using ExpressMapper for a more advanced scenarios, it is sometimes necessary to know the "final" (that is - after Compile() stage) mapping expressions. That would be possible if IMappingServiceProvider exposes some kind of ResultExpressions(Type src, Type dest) method which returns a collection of Expression based on TypeMapperBase<T, TN>'s ResultExpressionList property. If you think that's acceptable, I would happily submit a pull request with that feature :)

[anisimovyuriy]

Dear shay1e,

Thanks a lot for your input and contribution! I'd like to ask you about these advanced scenarios where the end-user would need them?

Thanks!

[shay1e]

I will give you an example -

Due to several requirements, we had to declare 3rd level models (types) except for the private and public (source and destination) models we have in our system. These models are a mirroring of the base models - each 3rd level class is a special representation of the source and target classes. (Polymorphism and traditional design patterns weren't suitable enough for this case). When registering and declaring members mappings between the source and destination models, we wanted to use the generated expressions (by collecting ResultExpressionList from all TypeMappers) to build customized mappings on runtime between the 3rd layers models and the source and destination models. In enterprise systems with large and sophisticated data access layers, like the one I'm working on, there are more than source and target types - each type has several representations which need to be mapped, and by fetching the base mapping results from ExpressMapper we can generate the other mappings on runtime. In another case, we had to not only to map fields, but also to initiate some logic based on the source and destination objects state. We solved this by expending the generated expression tree and add some more nodes to it. Of course, Like any other software issue this could done in many other ways without using expression trees at all. But the above solution gives the best performance, it is easy to maintain, and it uses expression trees! :)

By exposing the generated expressions, ExpressMapper would further from a (fantastic!) mappings black box to to a powerful multi purpose tool for systems that deal with many data transformations. Think of it this way: the results are not implementation details - they are a feature! :)

[strawd]

+1

We use the resulting expressions in AutoMapper today to figure out which db entity properties to filter on when a web request asks for a filter to a given DTO property, at least for simple cases.