In a previous post we saw that EF 2.1 is highly susceptible to the N+1 queries problem.
After the release of a new version of Entity Framework Core (EF) the first question coming to mind is: „Is it still a big issue in EF 3.1?“ And if the answer is no, is there anything else we have to be aware of?
In the previous blog post we used a navigational property to work around the limitations of the extension method GroupBy. The problem is, there is not always such a property we can use for grouping. Especially, when following domain driven design practices, a bidirectional navigation is undesirable to not to pollute the domain model (too much). Besides not introducing a navigational property intentionally there might be use cases when we have to group data by property such as the name of a record. In this case there simply cannot be a navigational property.
With Entity Framework Core 3.0 (EF) the internal implementation of the LINQ query translation has been changed a lot. So, some queries that didn’t work previously are working now and some that worked are not working anymore. 🙂
The Entity Framework Core (EF) extension method Include provides us the ability to load additional data besides the entities we are querying for. For example: loading products along with their translations.
In the blog post ROW_NUMBER Support we saw how to implement a custom function and in the previous post Improved Value Conversion Support we realized that inserting and selecting custom types is one thing but using them for filtering is something totally different.
Entity Framework Core (EF) 2.1 introduced a new feature called Value Conversion. Now, we are able to map custom .NET types to a type the database understands and vice versa. This long-awaited feature is especially popular among software engineers following the domain driven design (DDD) patterns.
In the previous post (Custom Functions – using IMethodCallTranslator) we looked at the more flexible approach that requires some boilerplate code. For the usage of a custom function in a project, especially if there are no plans to make the function public then the sacrifice of some (not required) flexibility to reduce the amount of code is fully acceptable.
In the previous blog post (Entity Framework Core: ROW_NUMBER Support) we saw how to use the custom function RowVersion with Entity Framework Core (EF). Now, we will look into the implementation.
There are some use cases that force me to use raw T-SQL instead of using LINQ.
Motivation One of the main queries in my projects is to select multiple database records
