Named Query Filters in .NET 10

From Hidden Magic to Clean, Explicit Architecture

Since their introduction in EF Core, Global Query Filters have offered a powerful idea:

define cross-cutting query rules once, and apply them automatically everywhere.

In theory, this reduces repetition and enforces consistency.

In practice, however, real-world usage exposed an important issue:

lack of clarity.

example :

public class UserConfiguration : IEntityTypeConfiguration<User>

{

    public void Configure(EntityTypeBuilder<User> builder)

    {

        builder.HasQueryFilter(u => u.IsDeleted == false);

        builder.ToTable(nameof(User));

    }

}

The Problem with Global Query Filters :

While useful, traditional Global Query Filters came with well-known drawbacks:

• Query behavior was not obvious when reading the code


• Filters were hidden inside model configuration


• Debugging missing data could be confusing


• New team members often had no idea why certain rows were excluded

In short, the rules existed — but they were unnamed and implicit.

Enter Named Query Filters in .NET 10

With Named Query Filters, .NET 10 doesn’t change the core concept it improves how the concept is expressed.

Instead of silent, invisible filters, we now have:

• Explicit names


• Clear intent


• Self-documenting rules

example :

public class UserConfiguration : IEntityTypeConfiguration<User>

{

    public void Configure(EntityTypeBuilder<User> builder)

    {

        builder.HasQueryFilter(UserFilters.SoftDelete,

                               u => u.IsDeleted == false);

        builder.ToTable(nameof(User));

    }

}

This is not just a cosmetic improvement; it’s an architectural one.

Why Naming Matters

In software design, naming is a first-class design decision.

When a query filter has a name:

• Code becomes easier to read


• Business rules become explicit


• Hidden behavior is reduced


• Team communication improves

This aligns naturally with:

• Clean Architecture


• Domain-Driven Design


• The Principle of Least Surprise

Using Query Filters as Design, Not a Trick

Query Filters — especially in their named form — work best when they represent

system-wide, stable rules, such as:

• Soft Delete


• Multi-Tenancy


• Data Isolation


• Global Security Constraints

Logic that changes per screen or use case should still live inside the query itself.

What Actually Improved?

With Named Query Filters:

• Rules are no longer hidden


• Query behavior is easier to understand


• Debugging becomes simpler


• Maintenance improves


• Architectural intent is clearer

Final Thoughts

Named Query Filters in .NET 10 demonstrate a subtle

but important shift:

moving from implicit behavior to explicit design. Small features like this don’t just clean up code , they improve how teams reason about systems.And that’s where real productivity gains come from.