Entity Framework Core 3.0 – “Hidden” GROUP BY Capabilities (Part 2)

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.

In this article:

Entity Framework Core 3.0 – “Hidden” GROUP BY Capabilities (Part 2)
Pawel Gerr is architect consultant at Thinktecture. He focuses on backends with .NET Core and knows Entity Framework inside out.

In this post we look at LINQ queries that behave in the same way as the navigational property we used in the previous post:

					var firstProducts = Context.ProductGroups  
   .Select(g => g.Products.OrderBy(p => p.Name).FirstOrDefault())  

Let’s achieve the same without using the property Products. Yet again, we start from the product groups but instead of using the navigational property we use the DbSet Products. The join condition between a group and the products is specified inside of the extension method FirstOrDefault.

					var firstProducts = Context.ProductGroups  
   .Select(g => Context.Products  
       .OrderBy(p => p.Name)  
       .FirstOrDefault(p => p.GroupId == g.Id))  

The generated SQL looks like the following:

					SELECT [t0].*  
   ProductGroups AS p  
      SELECT *  
         SELECT *, ROW_NUMBER() OVER(PARTITION BY p0.GroupId ORDER BY p0.Name) AS row  
         FROM [Products] AS [p0]  
      ) AS [t]  
      WHERE [t].[row] <= 1  
   ) AS t0 ON p.Id = t0.GroupId

The SQL statement is identical to the one that was generated when using the navigational property.

Now, imagine there is no DbSet ProductGroups and the property GroupId is just a regular property like Name. As a replacement for missing ProductGroups we use SELECT DISTINCT GroupId on the Products. The 2nd part of the query stays the same.

					var firstProducts = Context.Products  
   .Select(p => p.GroupId)  
   .Select(id => Context.Products  
        .OrderBy(p => p.Name)  
        .FirstOrDefault(p => p.GroupId == id))  


The generated SQL statement is:

					 SELECT [t1].*  
       SELECT DISTINCT p.GroupId  
       FROM Products AS p  
    ) AS t  
    LEFT JOIN (  
        SELECT t0.*  
        FROM (  
            SELECT p0.*, ROW_NUMBER() OVER(PARTITION BY p0.GroupId ORDER BY p0.Name) AS row  
            FROM Products AS p0  
        ) AS t0  
        WHERE t0.row <= 1  
    ) AS t1 ON t.GroupId = t1.GroupId

For grouping of data using built-in capabilities of Entity Framework Core 3.0 should be enough for most cases. For more advanced use cases we can’t do much but extending EF with custom functionality.

Demos: NavigationPropertiesAlternativeQueriesDemo.cs


Current articles, screencasts and interviews by our experts

Don’t miss any content on Angular, .NET Core, Blazor, Azure, and Kubernetes and sign up for our free monthly dev newsletter.

Related Articles
Roslyn Source Generators: Logging – Part 11
In previous part we lerned how to pass parameters to a Source Generator. In this article we need this knowledge to pass futher parameters to implement logging.
Roslyn Source Generators: Configuration – Part 10
In this article we will see how to pass configuration parameters to a Roslyn Source Generator to control the output or enable/disable features.
Roslyn Source Generators: Reduction of Resource Consumption in IDEs – Part 9
In this article we will see how to reduce the resource consumption of a Source Generator when running inside an IDE by redirecting the code generation to RegisterImplementationSourceOutput.