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.

var products = Context.Products
                      .Include(p => p.Translations)
                      .ToList();

--------------------------------------------------------------

public class Product
{
  public Guid Id { get; set; }
  public string Name { get; set; }
  public List<ProductTranslation> Translations { get; set; }
}

public class ProductTranslation
{
   public Guid ProductId { get; set; }
   public string Locale { get; set; }
   public string Description { get; set; }
}

In some use cases we want to load all translations for the requested products and in some cases we don't. There are plenty of times when we need translations for a specific locale (i.e. language) only but at the moment there is no built-in support for providing filters to entities being included. You may go to the corresponding github issue#1833 and vote for this feature to increase the priority of it.

Some of our options are:

Entity Framework Plus

Not much to say here. Install the nuget package and use the extension method IncludeFilter.

var products = Context.Products
                     .IncludeFilter(p => p.Translations.Where(t => t.Locale == "en"))
                     .ToList();

Please note that the generated queries will be different than when using built-in features of EF! To be aware of that is helpful especially during performance optimization, like finding appropriate database indexes.

Global Query Filters

The global query filters were introduced in EF 2.0 and are primarily for realization of features like soft delete and multi-tenancy. Although the filters are coupled to the entity type(s) and not to specific queries, still, we may enable and disable them at any time. Furthermore, despite the name the filters don't have to be "global", i.e. we can enable them for a specific instance of a DbContext only and not for all of them.

First, we introduce a variable that will be our filter and configure the corresponding query filter.

public class DemoDbContext : DbContext
{
   private string _localeFilter;

   protected override void OnModelCreating(ModelBuilder modelBuilder)
   {
      ...

      modelBuilder.Entity<ProductTranslation>()
                  .HasQueryFilter(t => _localeFilter == null 
                                       || t.Locale == _localeFilter);

   }

For setting the filter we could make the variable _localeFilter public but the API would not be that nice and robust, that's why ...

The method for enabling/setting the filter comes next.

   // we are still in DemoDbContext
   public IDisposable SetTranslationFilter(string locale)
   {
      if (locale == null)
         throw new ArgumentNullException(nameof(locale));
      if (_localeFilter != null)
         throw new InvalidOperationException($"Changing a filter is not allowed.");

      _localeFilter = locale;

      return new FilterReset(this);
   }

SetTranslationFilter is returning an IDisposable to not to forget to reset the filter. The FilterReset is a nested private struct inside DemoDbContext.

   private readonly struct FilterReset : IDisposable
   {
      private readonly DemoDbContext _ctx;

      public FilterReset(DemoDbContext ctx)
      {
         _ctx = ctx ?? throw new ArgumentNullException(nameof(ctx));
      }

      public void Dispose()
      {
         _ctx._localeFilter = null;
      }
   }

We are done with the implementation of the filter. The usage is looks as following: 

using (Context.SetTranslationFilter(locale))
{
   var products = Context.Products
                         .Include(p => p.Translations)
                         .ToList();
}

When using the global query filters in that manner then it is impossible that this filter is applied to other queries by accident because (1) the filter is bound to a specific instance of a DbContext and (2) a DbContext is not thread-safe so it must not be used in multiple threads concurrently.

Related Articles

entity framework core
Unnecessary Fuzzy Searches may hurt your Entity Framework Core Performance
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. What do I mean by…
Pawel Gerr
entity framework core
The performance issue "Cartesian Explosion" made its comeback in Entity Framework Core 3
In Entity Framework Core 3.0/3.1 the SQL statement generation underwent significant changes. As we have seen in the previous post these changes removed both the implicit client-side evaluation and the N+1 Query Problem (which is good!). Unfortunately, these changes (re)introduced…
Pawel Gerr
entity framework core
Is "N+1 Queries" still a performance issue in Entity Framework Core 3?
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…
Pawel Gerr
entity framework core
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 . 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…
Pawel Gerr