search

AutoMapper / AutoMapper.Extensions.OData

Creates LINQ expressions from ODataQueryOptions and executes the query.
MIT License
140 stars 38 forks source link

[Discussion/Question] What problem does this package aim to solve? #96

Closed stevendarby closed 3 years ago

stevendarby commented 3 years ago

Hello,

Originally (before discovering this package) we were starting with entityQuery.ProjectTo(_mapper) and then applying the OData options to that. This worked for the most part, but we had some issues in particular with filtering on nested properties in the DTO (EF having trouble translating to SQL etc.)

This package seems to help by (in loose terms) applying options to the entity query first e.g. by mapping the DTO filter expression to an entity filter expression, so that the ProjectTo comes last. This produces a query that is more easily translated by EF. Thank you!

While working through these problems and trying to find solutions I never really found any documentation explicitly dealing with the problem (i.e. “you can’t reliably apply odata options to (AutoMapper) projections”) or suggestions for solving it (e.g. “try this AutoMapper package which maps the DTO options to entity options”). The discovery of this was kind of an accident simply based on the fact it’s name crosses over OData/AutoMapper/EF and giving it a go.

So I was wondering if someone could confirm what I’ve covered above is the sort of problem this package seeks to solve. If that was the driver for creating this or if it was something else and this is just a happy side effect? Largely for my own understanding but it might also be something that could go in the readme or other AutoMapper documentation to help people understand potential pitfalls with OData and discover a solution?

Thanks

BlaiseD commented 3 years ago

Libraries in this repo were created in response to questions like this about expression translation.

By referencing Microsoft.AspNetCore.OData in this library (neither AutoMapper nor AutoMapper.Extensions.ExpressionMapping does) we have an opportunity to address more OData specific problems - see the open issues.

Your description correctly describes the differences between using this library vs using ProjectTo() directly. Historically filtering before projection has been recommended - I think that is still the case.

PRs are welcome for updating the ReadMe and addressing the open issues.

stevendarby commented 3 years ago

@BlaiseD Thank you

I’ve been doing a lot of experimenting today and found that upgrading from EF 3.1 to EF 5.0 fixed some issues such as filtering on second-level projected properties (i.e. the problem in the linked issue). That’s not to say all issues are solved in the latest EFs or that this package doesn’t still have lots of other useful applications and fixes- just thought I would mention one of my findings today.