Anyone who has worked with Entity Framework must have managed related entities. I believe many developers will agree the way that system works is difficult to reconcile with design patterns such as the Repository pattern. In this post, I’ll provide one quick and easy way to automatically load all related properties from the database.
Update 2018-11-26: Added the equivalent for EF Core.
By default, Entity Framework will load all “simple” types such as integers or string values. On the other, custom types such as the collection of Post objects aren’t in scope by default and will be null.
Of course, there is a method called “Include” that you can use to instruct Entity Framework to load the property with the specified parameter in the object graph:
You can add as many includes as you want, as long as you provide a property name. This doesn’t work very well if you are planning to implement a generic repository pattern. Because you don’t know the objects you’re working with, you can’t provide the names of your properties. And this is something you don’t want to know if you’re trying to make something generic.
Instead, I have a solution that automatically loads all navigation properties to the graph. If one of your requirements is performance, this probably won’t be the best solution. For that, I recommend you to look into query projections. Instead, if you want to have a comfortable way of accessing fully populated data, this is your answer.
Here is an example of a query that fetches the data with the possibility of adding a filter:
As you can see, this code sample also uses the Include statement, but it’s retrieving the parameters in runtime. Using the EF API, the current type is inspected and only the properties that are EntityTypes according to EF are included manually in the query. This code snippet offers some interesting perspectives to make it even more dynamic. Everything you see here is pure Entity Framework, no workarounds or whatsoever, so I like to think this as a sustainable solution.
For Entity Framework Core 2.0, this is the equivalent:
thanks for this interesting stuff, i wonder if its possible to include also navigation properties of nested navigation properties up to n-th level (or all)?
You could do this by using recursion. Within the loop you then should check the type, and if it is a complex type, you could run the same code as above (to include the properties). This way you don’t have to rewrite any code or do complex coding. Let me check this as soon as I have some time to investigate this. If you come up with a solution earlier, please get back to me so I can update this post!
i was not able to get EntityType from the NavigationProperty of given parent TEntity.
does work to thenInclude ?
Does it work for ThenInclude ?
I don’t think it would work as it is a generic method that doesn’t exactly know about the types that you pass in the includes parameter array. It is up to the developer to pass the correct navigation path as a string. This is entirely dynamic and possible to do at runtime, whereas the ThenInclude is a decision you make at compile time. If you know the requirements, then ThenInclude is the better fit. However, both approaches would return the same result in the end but with the dynamic approach, there’s a chance you’ll make mistakes which the compiler is not able to catch.