Unsere Artikel

It has been a while since I released my article about the usage of temp tables in Entity Framework (v6). Meanwhile, Microsoft has released a completely rewritten version of its O/R mapper so my old approach is no longer applicable. But before we learn about a new one, let us think about what we might need temp tables for.

Both a LINQ query and an SQL statement are descriptions that state which data should be fetched, but not how.. Sure, when reading LINQ or SQL, we can make assumptions about the performance but not in every case. Some queries are either too fancy or too big to grasp, so our predictions may be way too vague if we can make any at all.

After talking about performance issues like N+1 Queries and the Cartesian Explosion that made its comeback in Entity Framework Core 3, we will today look at a performance issue that is not tied to any Entity Framework version but is rather a general one.

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.