Efcore: Specification pattern with Include and ThenInclude

[ardalis]

I'm using the Specification pattern with EF Core, and am specifying what I want to include as part of the specification (along with query criteria).

See here:
https://github.com/dotnet-architecture/eShopOnWeb/blob/master/src/Infrastructure/Data/EfRepository.cs

Sample specification:
https://github.com/dotnet-architecture/eShopOnWeb/blob/master/src/ApplicationCore/Specifications/BasketWithItemsSpecification.cs

This all works great for .Include(), but I cannot figure out how to support .ThenInclude behavior within a Specification. Can you tell me if you think this is possible (and point me in the right direction), and if not, can you let me know if there are any plans to update EF Core's API to support this (i.e. perhaps supporting a different style of expression for .Include()?).

Thanks!

[ajcvickers]

@ardalis Have you tried using the string-based overloads of Include? When using strings, you don't need to have ThenInclude calls because you can instead use a concatenated string of properties. For example:
```C#
context.Products
.Include("NavA.NavB")
.ToList();

is the same as:
```C#
context.Products
    .Include(e => e.NavA)
    .ThenInclude(e => e.NavB)
    .ToList();

[ardalis]

That works, but has the usual disadvantages of magic strings (e.g. not picked up by automatic refactoring tools). Was hoping for something better, but this can be a workaround/stopgap approach.

[ajcvickers]

@ardalis I wasn't actually trying to suggest that you use strings in your repository API. Instead, I was thinking you could implement whatever lambda-based (or otherwise) API that makes sense for your patterns, not constrained in any way by ThenInclude or the other parts of the EF API. Once you have your API to your liking, then it should be fairly easy to generate the navigation property names from it and pass those to the Include string API without having to mess with EF's lambdas, etc.

[ardalis]

Yep, thanks. I'll give that a shot. More work on my end, but shouldn't be awful.