Coder Legion - Recent posts tagged ef

🚀 EF Core Query Optimization for Beginners

Mon, 29 Jun 2026 19:47:13 +0000

When developers first start using Entity Framework Core, it's easy to write queries that work—but not all queries perform well.

The good news? A few simple practices can make your queries much faster, use less memory, and generate better SQL.

We'll use this real-world example:

var offerDtos = await db.Offers
    .AsNoTracking()
    .Where(o => o.DeliveryDate >= date &&
                o.DeliveryDate < nextDay &&
                (o.IsCompleted == null || o.IsCompleted == 0))
    .OrderBy(o => o.Id)
    .Select(o => new OfferForWarehouseDto
    {
        OfferId = o.Id,
        CustomerName = o.Customer.Name,
        DeliveryDate = o.DeliveryDate,
        OfferDate = o.OfferDate,
        Status = o.Status,
        Comments = o.Comments,
        WarehouseStatus = "Pending",
        Lines = o.OfferLines
            .Select(l => new WarehouseLineDto
            {
                OfferLineId = l.Id,
                ItemCode = l.ItemCode,
                ItemDescription = l.ItemDescription,
                Color = l.Color,
                Unit = l.Unit,
                OrderedQuantity = l.Quantity,
                CurrentStock = l.Product.Stock
            })
            .ToList()
    })
    .ToListAsync(cancellationToken);

Let's break it down step by step.

1. Use `AsNoTracking()` for Read-Only Queries ⭐

.AsNoTracking()

One of EF Core's most useful features is the Change Tracker.

Whenever you load entities, EF Core tracks them in memory so it can detect changes and generate the appropriate INSERT, UPDATE, or DELETE statements when you call SaveChanges().

For example:

var offer = await db.Offers.FirstAsync();

offer.Status = "Completed";

await db.SaveChangesAsync();

Even though you never tell EF Core that Status changed, it knows because the Change Tracker has been monitoring the entity.

This is extremely convenient when you're editing data.

However, tracking every entity comes with a cost.

For each tracked entity, EF Core stores:

The original values
The current values
The entity state (Added, Modified, Deleted, Unchanged)
Relationship information

If you're only displaying data in a grid or returning it from an API, all of this tracking is unnecessary.

That's why read-only queries should use:

.AsNoTracking()

This tells EF Core:

"I'm only reading this data. Don't track it."

Benefits

✅ Lower memory usage
✅ Faster query execution
✅ Less CPU overhead
✅ Better performance for APIs, dashboards, and reports

Learn more

Change Tracking: https://learn.microsoft.com/en-us/ef/core/change-tracking/
Tracking vs. No-Tracking Queries: https://learn.microsoft.com/en-us/ef/core/querying/tracking

2. Filter Data Before Loading It

.Where(o =>
    o.DeliveryDate >= date &&
    o.DeliveryDate < nextDay &&
    (o.IsCompleted == null || o.IsCompleted == 0))

Always filter data in the database.

Good:

db.Offers.Where(...)

Bad:

db.Offers.ToList().Where(...)

The first generates a SQL WHERE clause.

The second loads the entire table into memory before filtering.

The database is optimized for filtering large datasets, so let it do the work.

3. Project Only What You Need

Notice that we're not returning Offer entities.

Instead, we're creating DTOs.

.Select(o => new OfferForWarehouseDto
{
    OfferId = o.Id,
    CustomerName = o.Customer.Name
})

This tells EF Core exactly which columns to retrieve.

Instead of:

SELECT *

EF Core generates SQL that selects only the properties used in the DTO.

Benefits include:

Smaller SQL results
Less network traffic
Lower memory usage
Faster execution

Learn more

https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying#project-only-properties-you-need

4. Don't Use `Include()` When Projecting

Many developers write:

.Include(o => o.Customer)
.Include(o => o.OfferLines)
.ThenInclude(l => l.Product)
.Select(...)

This is unnecessary.

When projecting into a DTO, EF Core automatically generates the required SQL joins.

Simply write:

.Select(...)

The generated SQL is usually smaller, cleaner, and more efficient.

5. Sort in SQL

Sorting should happen before materializing the results.

Good:

.OrderBy(o => o.Id)
.ToListAsync();

Bad:

.ToList()
.OrderBy(o => o.Id);

SQL Server is optimized for sorting data.

Don't move that work into your application.

6. Project Child Collections

EF Core can also project related collections.

Lines = o.OfferLines
    .Select(l => new WarehouseLineDto
    {
        ItemCode = l.ItemCode,
        CurrentStock = l.Product.Stock
    })
    .ToList()

Notice that we never load the entire OfferLine or Product entities.

Only the required columns are selected.

This keeps queries efficient while still returning nested objects.

7. Use Async Queries

Always prefer:

await ToListAsync();

instead of:

ToList();

Async queries don't make the database faster, but they prevent your application thread from blocking while waiting for SQL Server.

This improves scalability in ASP.NET Core applications.

8. Create Proper Database Indexes

Even the best LINQ query can be slow if the database has no indexes.

This query filters by:

DeliveryDate
IsCompleted

A composite index can dramatically improve performance.

CREATE INDEX IX_Offers_DeliveryDate_IsCompleted
ON Offers (DeliveryDate, IsCompleted);

Remember:

EF Core generates SQL.
SQL Server executes SQL.
Indexes make SQL fast.

Final Optimized Query

var offerDtos = await db.Offers
    .AsNoTracking()
    .Where(o => o.DeliveryDate >= date &&
                o.DeliveryDate < nextDay &&
                (o.IsCompleted == null || o.IsCompleted == 0))
    .OrderBy(o => o.Id)
    .Select(o => new OfferForWarehouseDto
    {
        OfferId = o.Id,
        CustomerName = o.Customer.Name,
        DeliveryDate = o.DeliveryDate,
        OfferDate = o.OfferDate,
        Status = o.Status,
        Comments = o.Comments,
        WarehouseStatus = "Pending",
        Lines = o.OfferLines
            .Select(l => new WarehouseLineDto
            {
                OfferLineId = l.Id,
                ItemCode = l.ItemCode,
                ItemDescription = l.ItemDescription,
                Color = l.Color,
                Unit = l.Unit,
                OrderedQuantity = l.Quantity,
                CurrentStock = l.Product.Stock
            })
            .ToList()
    })
    .ToListAsync(cancellationToken);

🎯 Key Takeaways

Whenever you write an EF Core query, ask yourself:

✅ Is this a read-only query? → Use AsNoTracking().
✅ Am I letting the database filter my data?
✅ Am I selecting only the columns I need?
✅ Am I avoiding unnecessary Include() calls?
✅ Am I using async methods like ToListAsync()?
✅ Does my database have the right indexes?

Following these simple habits will help you write faster, cleaner, and more scalable EF Core applications.

Additional Resources

EF Core Performance: https://learn.microsoft.com/en-us/ef/core/performance/
Efficient Querying: https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying
Change Tracking: https://learn.microsoft.com/en-us/ef/core/change-tracking/
Tracking vs. No-Tracking Queries: https://learn.microsoft.com/en-us/ef/core/querying/tracking

5 EF Core Features Every Enterprise Developer Should Know

Fri, 05 Jun 2026 08:47:24 +0000

Entity Framework Core (EF Core) is often introduced as an ORM that simplifies data access, but its real value in enterprise applications comes from features that improve reliability, scalability, and maintainability.

As applications grow and operate in cloud environments, these capabilities become essential rather than optional.

1. Connection Resiliency and Retry Policies

Enterprise systems frequently run on cloud-hosted databases where transient network failures, failovers, and throttling can occur. EF Core provides built-in connection resiliency by automatically retrying failed database operations.

options.UseSqlServer(connectionString, sqlOptions =>
    sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(10),
        errorNumbersToAdd: null));

This helps applications recover gracefully from temporary infrastructure issues without requiring custom retry logic throughout the codebase.

2. Optimistic Concurrency Control

In multi-user systems, preventing lost updates is critical. EF Core supports optimistic concurrency through concurrency tokens such as SQL Server's rowversion.

public class Order
{
    public int Id { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; }
}

When another user modifies the same record, EF Core detects the conflict and throws a DbUpdateConcurrencyException, allowing the application to reload, merge, or notify the user. This ensures data integrity while avoiding expensive database locks.

3. Performance Optimization with Compiled Queries

High-throughput APIs and microservices can execute the same queries thousands of times per second. EF Core offers several performance features, including compiled queries, AsNoTracking, query splitting, and batching.

private static readonly Func<AppDbContext, int, Task<Order>> GetOrder =
    EF.CompileAsyncQuery((AppDbContext ctx, int id) =>
        ctx.Orders.AsNoTracking()
                  .FirstOrDefault(o => o.Id == id));

Compiled queries eliminate repeated LINQ-to-SQL translation overhead, while AsNoTracking reduces change-tracking costs for read-only operations. These optimizations can significantly improve throughput under load.

4. Transactions and Unit of Work

Business operations often involve multiple database changes that must either succeed together or fail together. EF Core supports explicit transactions to guarantee atomicity.

await using var tx = await context.Database.BeginTransactionAsync();

try
{
    await context.SaveChangesAsync();
    await otherContext.SaveChangesAsync();
    await tx.CommitAsync();
}
catch
{
    await tx.RollbackAsync();
    throw;
}

This capability is fundamental for maintaining consistency across aggregates, repositories, and critical business workflows.

5. Global Query Filters

Global query filters allow rules to be applied automatically to every query for a given entity. They are especially valuable for multi-tenant SaaS applications and soft-delete implementations.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Customer>()
        .HasQueryFilter(c => !c.IsDeleted);

    modelBuilder.Entity<Invoice>()
        .HasQueryFilter(x => x.TenantId == _currentTenant.Id);
}

By centralizing these concerns, developers reduce duplication and eliminate the risk of accidentally exposing data across tenants or returning deleted records.

Final Thoughts

While EF Core is easy to start with, enterprise applications require more than basic CRUD operations. Features such as connection resiliency, concurrency control, performance optimization, transactions, and global query filters help teams build systems that are robust, scalable, and maintainable in production.

Mastering these five capabilities will provide a strong foundation for building enterprise-grade applications with EF Core.

When IDbContextFactory enters the chat, and what it actually fixes.

Mon, 16 Feb 2026 09:47:23 +0000

When `IDbContextFactory` enters the chat, and what it actually fixes

Most EF Core examples use a scoped DbContext. In a normal Web API request, that’s fine, the request ends, the context is disposed.

Then you build Blazor Server.

A Blazor Server circuit can stay alive for a long time, minutes or hours. If your DbContext is scoped, it can also stay alive that long. That’s when things start to break in annoying ways.

What problems show up

1) “A second operation was started on this context…”
DbContext is not thread-safe. In Blazor Server it’s easy to trigger overlapping work (clicks, timers, loading states). If two queries happen at the same time on the same context, you get this error.

2) Tracking bloat
A long-lived context keeps tracking entities. Over time:

memory grows
queries can feel slower
SaveChanges can get heavy
you hit “already being tracked” errors

3) Stale or confusing data
Because the context tracks objects, you can end up reusing old instances without realizing it, the UI feels out of sync.

What `IDbContextFactory` changes

It gives you a fresh DbContext per operation.

create context
run the query or command
dispose the context

So each click, each load, each action gets its own clean context. No shared state, no concurrency fights, no growing tracker.

When to use it

Use IDbContextFactory when you have:

Blazor Server
background jobs or hosted services
timers, polling, signalR style event flows
any parallel DB work

In simple controller-per-request apps, scoped DbContext is still perfectly fine.

The takeaway

IDbContextFactory is not a “nice to have”, it’s the safer default when your app is long-lived and event-driven. It prevents a whole category of EF Core bugs before they happen.

Source Code :

https://github.com/stevsharp/BlazorFactoryDemo

Reliable Messaging in .NET: Domain Events and the Outbox Pattern with EF Core Interceptors

Mon, 13 Oct 2025 11:27:53 +0000

Introduction

Distributed systems are powerful — but they come with one big challenge: reliability.

What happens if your application updates a record in the database and then tries to publish a message to a message broker… but crashes in between?
You’ve just lost an event.

This problem is common in microservices, and it’s why the Outbox Pattern exists — a simple, elegant approach that guarantees message delivery without introducing distributed transactions or external coordinators.

In this article, we’ll implement a Domain Event + Outbox Pattern in .NET 9, using Entity Framework Core, SQLite, and an EF Core SaveChangesInterceptor.

⚙️ A Quick Look at Entity Framework Core

Entity Framework Core (EF Core) is Microsoft’s modern Object-Relational Mapper (ORM) for .NET.
It allows developers to work with a database using C# classes instead of raw SQL, automatically handling relationships, migrations, and change tracking.

When you call SaveChanges() or SaveChangesAsync(), EF Core:

Tracks your entity changes.
Generates SQL commands.
Executes them in a transaction.

This makes EF Core the perfect place to integrate the Outbox Pattern, since we can hook into its save pipeline and ensure domain events are written in the same transaction as the data itself.

What Are Interceptors?

In EF Core, interceptors are powerful hooks that allow you to intercept and extend the framework’s internal operations — such as saving, querying, or connecting to the database.

They work like middleware for EF Core:
you can observe, modify, or add logic before and after EF performs certain actions.

There are several types:

SaveChangesInterceptor
CommandInterceptor
ConnectionInterceptor
TransactionInterceptor

In this article, we’ll use SaveChangesInterceptor to detect domain events before EF saves, serialize them, and insert them into our Outbox table.

The Problem

In traditional architectures, your service might do something like this:

await _db.SaveChangesAsync();
await _bus.PublishAsync(new OrderPlacedEvent(orderId));

If your app crashes after saving but before publishing, your event never reaches other services — resulting in inconsistent state across systems.

We need a way to ensure atomicity: either both the data and the event are persisted, or neither are.

The Outbox Pattern (In a Nutshell)

The Outbox Pattern solves this by introducing a dedicated Outbox table inside your database.

When your aggregate raises a domain event, it’s captured and saved into the Outbox table within the same transaction as your entity.
A background worker (or a separate service) polls the Outbox table, publishes events, and marks them as processed.

This way, even if your app crashes, the events are safely stored and can be retried later.

The Architecture

┌──────────────────────────────┐
│         Application          │
│ ──────────────────────────── │
│  Order raises DomainEvent    │
│  → EF Interceptor writes     │
│    Outbox row                │
│  → Transaction commits       │
└──────────────┬───────────────┘
               │
               ▼
        Outbox Dispatcher
       ├─ Polls database
       ├─ Publishes messages
       └─ Marks them processed

This pattern elegantly blends Domain-Driven Design concepts with event-driven reliability.

Domain Events

Domain events capture something meaningful that happened in your domain model.
For example:

public sealed record OrderPlacedDomainEvent(Guid OrderId, decimal Total)
    : DomainEvent(DateTime.UtcNow);

And your aggregate raises them naturally:

public sealed class Order : IHasDomainEvents
{
    private readonly List<DomainEvent> _domainEvents = new();
    public Guid Id { get; private set; } = Guid.NewGuid();
    public decimal Total { get; private set; }

    public IReadOnlyCollection<DomainEvent> DomainEvents => _domainEvents;

    public Order(decimal total)
    {
        Total = total;
        AddEvent(new OrderPlacedDomainEvent(Id, Total));
    }

    private void AddEvent(DomainEvent @event) => _domainEvents.Add(@event);
    public void ClearDomainEvents() => _domainEvents.Clear();
}

⚙️ Capturing Events with an EF Core Interceptor

Instead of overriding SaveChangesAsync() directly inside AppDbContext, we can use a SaveChangesInterceptor — a clean, composable way to plug custom logic into EF’s lifecycle.


public sealed class OutboxSaveChangesInterceptor(IEventSerializer serializer) : SaveChangesInterceptor
{
    /// <summary>
    /// 
    /// </summary>
    /// <param name="eventData"></param>
    /// <param name="result"></param>
    /// <param name="cancellationToken"></param>
    /// <returns></returns>
    public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData,
        InterceptionResult<int> result,
        CancellationToken cancellationToken = default)
    {
        var context = eventData.Context;
        if (context is null) 
            return await base.SavingChangesAsync(eventData, result, cancellationToken);

        var aggregates = context.ChangeTracker
                    .Entries()
                    .Where(e => e.Entity is IHasDomainEvents hasEvents && hasEvents.DomainEvents.Count > 0)
                    .Select(e => (IHasDomainEvents)e.Entity)
                    .ToList();

        if (aggregates.Count == 0)
            return await base.SavingChangesAsync(eventData, result, cancellationToken);

        var outbox = context.Set<OutboxMessage>();

        foreach (var aggregate in aggregates)
        {
            foreach (var @event in aggregate.DomainEvents)
            {
                outbox.Add(new OutboxMessage
                {
                    OccurredOnUtc = @event.OccurredOnUtc,
                    Type = @event.GetType().AssemblyQualifiedName!,
                    Payload = serializer.Serialize(@event)
                });
            }
        }

        return await base.SavingChangesAsync(eventData, result, cancellationToken);
    }

}

Now every time you call SaveChangesAsync(), domain events are written to your OutboxMessages table automatically — in the same transaction.

The Outbox Dispatcher

Once the transaction is committed, a background worker can safely process these messages.


public sealed class OutboxDispatcher(IServiceProvider sp, 
    ILogger<OutboxDispatcher> logger) : BackgroundService
{
    private readonly IServiceProvider _sp = sp;
    private readonly ILogger<OutboxDispatcher> _logger = logger;
    private readonly TimeSpan _pollInterval = TimeSpan.FromSeconds(2);
    private const int BatchSize = 50;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation(" Outbox Dispatcher started...");

        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                using var scope = _sp.CreateScope();
                var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

                var jsonSerializer = scope.ServiceProvider.GetRequiredService<IEventSerializer>();

                var pending = await db.OutboxMessages
                    .Where(x => x.ProcessedOnUtc == null)
                    .OrderBy(x => x.Id)
                    .Take(BatchSize)
                    .ToListAsync(stoppingToken);

                foreach (var msg in pending)
                {
                    try
                    {
                        var evt = jsonSerializer.Deserialize(msg.Payload, msg.Type);
                        await SimulatedBusPublish(evt, stoppingToken);
                        msg.ProcessedOnUtc = DateTime.UtcNow;
                        msg.Error = null;
                    }
                    catch (Exception ex)
                    {
                        msg.Error = ex.Message;
                        _logger.LogError(ex, "❌ Error dispatching OutboxMessage {Id}", msg.Id);
                    }
                }

                if (pending.Count > 0)
                    await db.SaveChangesAsync(stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Outbox dispatcher loop error");
            }

            await Task.Delay(_pollInterval, stoppingToken);
        }
    }

    private Task SimulatedBusPublish(DomainEvent evt, CancellationToken ct)
        => evt switch
        {
            OrderPlacedDomainEvent e => HandleOrderPlaced(e),
            _ => Task.CompletedTask
        };

    private Task HandleOrderPlaced(OrderPlacedDomainEvent e)
    {
        Console.WriteLine($"[BUS] ✅ OrderPlaced published => OrderId={e.OrderId}, Total={e.Total}");

        return Task.CompletedTask;
    }
}

Why Use an Interceptor?

Using an interceptor instead of overriding SaveChangesAsync() has several advantages:

Approach	Pros	Cons
Override SaveChangesAsync	Simple to start	Harder to reuse across contexts
Use Interceptor	Decoupled, reusable, testable	Slightly more setup

Interceptors follow the Open/Closed Principle — your DbContext remains focused on persistence, while cross-cutting logic (like event logging, auditing, or outbox handling) is easily attachable.

Benefits of the Outbox Pattern

✅ Transactional Safety — data + events saved atomically
✅ Guaranteed Delivery — retries handled by dispatcher
✅ DDD Alignment — aggregates raise domain events naturally
✅ Resilience — works even if message broker is offline
✅ Extensibility — can integrate with RabbitMQ, Kafka, or Azure Service Bus later

References

✨ Closing Thoughts

The Domain Events + Outbox Pattern is one of the most practical ways to achieve reliable, eventually consistent event-driven systems in .NET.

By combining Entity Framework Core, SaveChangesInterceptor, and a simple background dispatcher, you can ensure every event is persisted and delivered — even in the face of failure.

Small pattern. Big reliability.

Author

Spyros Ponaris
LinkedIn
Senior Software Engineer & .NET Enthusiast

Supercharging EF Core Specifications with EF.CompileQuery

Tue, 05 Aug 2025 07:56:23 +0000

Introduction

When you’re using EF Core in production, query compilation can quietly become a performance bottleneck — especially if the same query is executed thousands of times.

Normally, EF Core parses your LINQ, generates SQL, and prepares the execution plan every time.
With EF.CompileQuery, EF Core does that work once, caching the query plan for all future executions.

The catch?

If you’re using the Specification pattern for clean, reusable queries, your repository method probably applies a spec dynamically to DbSet — which makes EF.CompileQuery less obvious to use.

In this article, we’ll solve that and show you how to bake compiled queries into your specification-driven repository.

Quick Recap: Specification Pattern

The Specification pattern encapsulates query logic into reusable, composable units.

Example spec for active customers:

public class ActiveCustomersSpec : Specification<Customer>
{
    public ActiveCustomersSpec()
    {
        Query.Where(c => c.IsActive)
             .OrderBy(c => c.Name)
             .Include(c => c.Orders);
    }
}

Your repository then applies the spec:

public async Task<IReadOnlyList<T>> ListAsync(ISpecification<T> spec)
{
    var evaluator = new SpecificationEvaluator();
    var query = evaluator.GetQuery(_db.Set<T>().AsQueryable(), spec);
    return await query.ToListAsync();
}

The Problem

EF.CompileQuery needs a strongly-typed lambda starting from your DbContext:

private static readonly Func<AppDbContext, bool, IEnumerable<Customer>> _activeCustomers =
    EF.CompileQuery((AppDbContext db, bool isActive) =>
        db.Customers.Where(c => c.IsActive == isActive));

But with the Specification pattern, you usually pass in a spec, not a lambda on DbContext.
You don’t want every caller to remember how to invoke the compiled query.
We need a way to integrate compiled queries into the repository itself.

The Solution: Encapsulate Compiled Queries in the Repository

4.1 Create the compiled query

public static class CompiledQueries
{
    public static readonly Func<AppDbContext, bool, IEnumerable<Customer>> ActiveCustomers =
        EF.CompileQuery((AppDbContext db, bool isActive) =>
            db.Customers
              .Where(c => c.IsActive == isActive)
              .OrderBy(c => c.Name)
              .Include(c => c.Orders));
}

4.2 Update the repository

public class EfRepository<T> where T : class
{
    private readonly AppDbContext _db;
    public EfRepository(AppDbContext db) => _db = db;

    public async Task<IReadOnlyList<T>> ListAsync(ISpecification<T> spec)
    {
        // Detect known spec → use compiled query
        if (typeof(T) == typeof(Customer) && spec is ActiveCustomersSpec)
        {
            var result = CompiledQueries.ActiveCustomers(_db, true).ToList();
            return (IReadOnlyList<T>)result;
        }

        // Fallback: normal spec evaluation
        var evaluator = new SpecificationEvaluator();
        var query = evaluator.GetQuery(_db.Set<T>().AsQueryable(), spec);
        return await query.ToListAsync();
    }
}

4.3 Usage stays clean

var repo = new EfRepository<Customer>(db);
var customers = await repo.ListAsync(new ActiveCustomersSpec());

The caller doesn’t know (or care) if the query was compiled
but hot-path specs now run ~3x faster.

Ready-to-Use Libraries
Instead of writing your own Specification pattern, you can use:

Ardalis.Specification

Well-maintained, feature-rich.
Supports includes, projections, ordering, pagination.

NSpecifications

DDD-focused, composable specifications.
Great for domain-driven designs.

Both integrate nicely with EF Core and can work with this
compiled-query approach.

Best Practices
Use compiled queries for hot paths — they have a cost to set up but shine when reused often.

Avoid over-compiling — not every query benefits from precompilation.

Keep specs small and focused — huge includes and joins can still dominate runtime.

Combine with async wisely — EF.CompileQuery is sync; use EF.CompileAsyncQuery for async enumeration.

Conclusion

You don’t have to choose between clean architecture (Specification pattern) and speed.
By encapsulating EF.CompileQuery inside your repository for frequently-used specs,
you can keep your calling code clean while still getting huge performance wins.

Source Code :
https://github.com/stevsharp/EfCompileSpecDemo

⚔️ The Mighty MERGE: Using SQL Merge Statements Safely with EF Core

Fri, 25 Jul 2025 12:16:46 +0000

When you’re working with bulk data operations, upserts, or syncing external sources, MERGE is one of the most powerful tools SQL Server offers. But what happens when you need to use it alongside Entity Framework Core?

In this article, we’ll cover:

✅ What MERGE is and why it matters

How to use it with EF Core (with and without transactions)

⚠️ Common pitfalls and best practices

️ Alternatives like BulkExtensions and PostgreSQL upserts

When to use MERGE — and when not to

What Is SQL MERGE?

MERGE is a T-SQL command that allows you to INSERT, UPDATE, or DELETE in a single statement based on conditions between a source and a target.

Simple Example:

MERGE INTO Products AS Target
USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
    ON Target.Id = Source.Id
WHEN MATCHED THEN
    UPDATE SET Name = Source.Name
WHEN NOT MATCHED THEN
    INSERT (Id, Name) VALUES (Source.Id, Source.Name);

✅ The power of MERGE lies in combining multiple operations in one atomic transaction — perfect for syncing external sources, staging tables, or upserting data without multiple round-trips.

Using MERGE with EF Core
EF Core does not expose MERGE as part of its LINQ API. But you can still run raw SQL safely using:

Option 1: ExecuteSqlRaw

await dbContext.Database.ExecuteSqlRawAsync(@"
MERGE INTO Products AS Target
USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
ON Target.Id = Source.Id
WHEN MATCHED THEN
    UPDATE SET Name = Source.Name
WHEN NOT MATCHED THEN
    INSERT (Id, Name) VALUES (Source.Id, Source.Name);");

Option 2: Call a Stored Procedure

CREATE PROCEDURE MergeProducts AS
BEGIN
    MERGE INTO Products ...
END

await dbContext.Database.ExecuteSqlRawAsync("EXEC MergeProducts");

Option 3: Use EF Core Bulk Libraries

Libraries like EFCore.BulkExtensions simulate efficient MERGE behavior:

await dbContext.BulkInsertOrUpdateAsync(products);

Can I Use MERGE with EF Core Transactions?

Yes — and you should if you’re performing other EF operations in the same workflow. EF Core supports shared transactions across both raw SQL and EF operations.

✅ Full Example:

using var transaction = await dbContext.Database.BeginTransactionAsync();

try
{
    // 1. Execute MERGE
    await dbContext.Database.ExecuteSqlRawAsync(@"
        MERGE INTO Products AS Target
        USING (VALUES (1, 'Apple'), (2, 'Banana')) AS Source(Id, Name)
        ON Target.Id = Source.Id
        WHEN MATCHED THEN
            UPDATE SET Name = Source.Name
        WHEN NOT MATCHED THEN
            INSERT (Id, Name) VALUES (Source.Id, Source.Name);");

    dbContext.SyncLogs.Add(new SyncLog { Table = "Products", Timestamp = DateTime.UtcNow });
    await dbContext.SaveChangesAsync();

    await transaction.CommitAsync();
}
    catch
{
    await transaction.RollbackAsync();
    throw;
}

✅ This ensures the MERGE and the SyncLogs insert are part of the same database transaction, protecting you from partial updates.

⚠️ Warnings About SQL Server MERGE

Microsoft has acknowledged multiple bugs with MERGE in SQL Server — including:

https://learn.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql?view=sql-server-ver16#remarks

Unexpected behavior with triggers

Incorrect OUTPUT clauses

Problems with concurrent updates

✅ Safer Patterns

Use UPDATE ... and INSERT WHERE NOT EXISTS if possible

Avoid complex MERGE statements with multiple joins

Always test MERGE inside a transaction in production-like data scenarios

When Should I Use MERGE?

✅ Use MERGE if:

You need to sync two tables (e.g., staging import)

You want to upsert large volumes in one atomic step

You’re doing data warehousing or ETL pipelines

❌ Avoid MERGE if:

You're only updating/inserting a few rows

You rely on entity validation logic in your app

You need maximum concurrency safety without side effects

✨ Bonus: Reusable MERGE Helper
You can build a helper that accepts any raw SQL and executes it within a transaction:

public static async Task ExecuteMergeAsync(this DbContext db, string sql)
{
    using var tx = await db.Database.BeginTransactionAsync();
    try
    {
        await db.Database.ExecuteSqlRawAsync(sql);
        await tx.CommitAsync();
    }
    catch
    {
        await tx.RollbackAsync();
        throw;
    }

}

Conclusion

SQL MERGE is a mighty tool for any developer working with bulk updates, external data, or data sync pipelines. EF Core doesn’t have built-in support but raw SQL, stored procs, and bulk extensions let you use it safely and effectively.

Wrap it in transactions, know when it shines, and watch out for its quirks and you’ll get the best of both SQL Server and EF Core worlds.

Optimistic vs. Pessimistic Concurrency in EF Core (with Table Hints)

Mon, 31 Mar 2025 10:01:25 +0000

Many experienced developers are familiar with database transactions but often overlook the key differences between optimistic and pessimistic concurrency control in Entity Framework Core (EF Core).

Understanding both approaches and how EF Core handles concurrency tokens is essential for building scalable and safe data operations, especially in systems with high transaction rates.

Concurrency control determines how multiple users or processes interact with the same data simultaneously. While optimistic concurrency is the default in EF Core, pessimistic concurrency is often misunderstood, misused, or completely ignored even by seniors engineers.

You can find the full code example at:
https://github.com/stevsharp/EfCoreExamples/tree/Efcore-Concurrency

What Is a Concurrency Token?

A concurrency token is a property that EF Core watches to detect whether a row has been modified since it was loaded. It's typically used in optimistic concurrency scenarios.

EF Core uses this token during SaveChangesAsync() to generate a WHERE clause that checks if the value is unchanged , if it has changed, a DbUpdateConcurrencyException is thrown.

How to Mark a Property as a Concurrency Token

✅ Using [ConcurrencyCheck] Attribute:

public class Product
{
    public int Id { get; set; }

    [ConcurrencyCheck]
    public int Stock { get; set; }
}

✅ Using [Timestamp] (for SQL Server rowversion column):

[Timestamp]
public byte[] RowVersion { get; set; }

✅ Fluent Configuration:

modelBuilder.Entity<Product>()
    .Property(p => p.Stock)
    .IsConcurrencyToken();

You can use any column as a concurrency token — even logical fields like LastModified, but (aka ) is the most reliable for SQL Server.

Optimistic Concurrency Control

Optimistic concurrency assumes conflicts are rare, so it doesn’t lock any data during updates. Instead, it tracks changes using concurrency tokens and throws an exception if a conflict is detected during SaveChangesAsync().

✅ When to Use

Read-heavy apps with occasional writes (e.g., blog, e-commerce frontend)

Systems where retries are acceptable

How to Implement in EF Core with a Concurrency Token

Entity:

public class Product
{
    public int Id { get; set; }
    public int Stock { get; set; }

    [Timestamp] // This is the concurrency token
    public byte[] RowVersion { get; set; }
}

Save and Handle Concurrency:

var product = await context.Products.FindAsync(1);

if (product.Stock > 0)
{
    product.Stock -= 1;

    try
    {
        await context.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException ex)
    {
        var databaseValues = await ex.Entries.Single().GetDatabaseValuesAsync();
        ex.Entries.Single().OriginalValues.SetValues(databaseValues);
    }
}

Pessimistic Concurrency Control

Pessimistic concurrency prevents conflicts altogether by locking the rows being read or modified. This ensures no one else can change the data until the transaction is complete.

❗ Important: EF Core does not support table hints like `` in LINQ. These must be applied using raw SQL.

Example: Locking Bank Account Row

using (var context = new AppDbContext())
{
    using var transaction = await context.Database.BeginTransactionAsync();

    var account = await context.Accounts
        .FromSqlRaw("SELECT * FROM Accounts WITH (UPDLOCK, ROWLOCK) WHERE Id = {0}", 1)
        .AsTracking() // Ensures the entity is tracked for updates
        .FirstOrDefaultAsync();

    if (account != null)
    {
        account.Balance -= 100;

        await context.SaveChangesAsync();
    }

    await transaction.CommitAsync();

}

Why SaveChangesAsync() Alone Is Not Always Enough

When using FromSqlRaw(), EF Core may not track the entity correctly for updates unless explicitly instructed.

Using .AsTracking() ensures EF will detect changes.

Without it, you would need to manually mark the entity as modified:

context.Entry(account).State = EntityState.Modified;

✅ Final Thoughts

Concurrency tokens (like RowVersion) play a central role in optimistic concurrency, enabling EF Core to detect conflicts without using locks.

Optimistic concurrency is ideal for most applications where data collisions are rare and performance is key.

Pessimistic concurrency is essential in financial or high-risk systems, where consistency outweighs performance.

EF Core does not support table hints like ` in LINQ, but you can **leverage them via **`, with .AsTracking() to ensure updates are recognized.

Many developers — even experienced ones — underestimate how concurrency should be managed in EF Core. The wrong approach can result in subtle bugs, lost data, or race conditions in production.

References & Further Reading

Microsoft Docs – Handling Concurrency Conflicts in EF Core

Microsoft Docs – Concurrency Tokens

Dev.to – Understanding and Using Table Hints in SQL Server

Microsoft Docs – Raw SQL Queries in EF Core

SQL Server – Table Hints in Transact-SQL

EF Core Bulk Updates and Deletes: Performance vs Change Tracking

Mon, 24 Mar 2025 20:25:26 +0000

Entity Framework Core 7 introduced two powerful methods for bulk operations:

ExecuteUpdateAsync and ExecuteDeleteAsync.

These methods are designed for high-performance scenarios where you need to update or delete multiple records efficiently without loading them into memory. They work great, but there's one caveat: EF Core's Change Tracker is not aware of these changes.

In this article, we explore how these methods work, why they bypass the Change Tracker, and most importantly—how you can audit or track changes manually when using them.

If you're not familiar with EF Core's Change Tracker, check out this introductory guide on Change Tracking to understand how EF Core monitors entity states.

Why Use ExecuteUpdateAsync and ExecuteDeleteAsync?

These methods:

Generate direct SQL UPDATE and DELETE statements.
Do not load entities into memory, improving performance.
Bypass change tracking, which avoids unnecessary overhead.

Example Usage:

// Bulk update
await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .ExecuteUpdateAsync(setters => setters.SetProperty(u => u.IsInactive, true));

// Bulk delete
await context.Users
    .Where(u => u.IsInactive)
    .ExecuteDeleteAsync();

The Problem: No Change Tracking

Because EF Core does not load entities into memory during these operations, the Change Tracker never sees them. This means:

No automatic change detection.
No SaveChangesAsync() involvement.
No triggers for audit or domain events.

So, how do you track what was changed or deleted?

1.Auditing Options for Bulk Operations

Manual Pre-Query Before Execution

Fetch affected entities before performing the batch operation.

var affectedUsers = await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .Select(u => new { u.Id, u.Name, OldValue = u.IsInactive })
    .ToListAsync();

await context.Users
    .Where(u => u.LastLogin < DateTime.UtcNow.AddYears(-1))
    .ExecuteUpdateAsync(setters => setters.SetProperty(u => u.IsInactive, true));

// Log changes manually
foreach (var user in affectedUsers)
{
    Console.WriteLine($"User {user.Name} updated: IsInactive {user.OldValue} → true");
}

Pros:

Precise control over what you log.

Access to old values.

Cons:

Requires an extra query.

May impact performance for large datasets.

Audit Table Logging

Save the affected data into an audit table before executing the bulk operation.

Example:

await context.AuditLogs.AddRangeAsync(affectedUsers.Select(user => new AuditLog
{
    EntityName = "User",
    EntityId = user.Id,
    ChangeType = "Updated",
    ChangedAt = DateTime.UtcNow,
    Description = $"User {user.Name} was updated: IsInactive {user.OldValue} → true"
}));

await context.SaveChangesAsync();

Database Triggers

Define SQL triggers to capture changes directly in the database.

Example :

CREATE TRIGGER trg_User_Delete
ON Users
AFTER DELETE
AS
BEGIN
    INSERT INTO AuditLogs (EntityName, EntityId, ChangeType, ChangedAt, Description)
    SELECT 'User', Id, 'Deleted', GETUTCDATE(), CONCAT('User ', Name, ' was deleted') FROM deleted;
END;

Pros:

Fully automated.

Ensures auditing even if EF Core is bypassed.

Cons:

Less flexible.

Harder to manage and version control.

EF Core Interceptors (Advanced)

Capture executed SQL commands using DbCommandInterceptor.

Limitation:

You can log the SQL query but not the previous values of affected entities.

public class AuditInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, CommandEventData eventData, InterceptionResult<DbDataReader> result)
    {
        Console.WriteLine($"SQL Executed: {command.CommandText}");
        return base.ReaderExecuting(command, eventData, result);
    }
}

Registering the Interceptor :

public class ApplicationDbContext : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<AuditLog> AuditLogs { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer("YourConnectionStringHere");
        optionsBuilder.AddInterceptors(new AuditInterceptor());
    }

Conclusion

EF Core's ExecuteUpdateAsync and ExecuteDeleteAsync offer incredible performance for bulk data operations but come at the cost of losing automatic change tracking.

If you need to audit or track changes, the best approach is to manually query the affected data before execution or use a dedicated audit system such as audit tables or SQL triggers.

Choose the method that balances performance and auditing needs for your application.

What do you think? Do you prefer performance with manual tracking, or do you rely on EF Core's change tracking? Let us know your approach!

You can find the full code example at: https://github.com/stevsharp/EfCoreExamples/tree/BulkUpdateAndDeletes

References

Microsoft Docs - EF Core 7: ExecuteUpdate and ExecuteDelete

Microsoft Docs - Change Tracking in EF Core

Microsoft Docs - Interceptors in EF Core

Community Discussion - EF Core GitHub Issue on Change Tracking and Bulk Operations

EF Core Interceptors: Supercharge Your Data Access with the Decorator Pattern

Thu, 20 Mar 2025 08:25:11 +0000

Learn how to hook into EF Core operations using interceptors, leverage the Decorator Pattern for clean cross-cutting concerns, and see real-world examples like SQL logging and auditing.

Table of Contents

A Brief History of EF Core Interceptors
What Are EF Core Interceptors?
EF Core Interceptors and the Decorator Pattern
Top Use Cases for EF Core Interceptors
Example 1: Logging SQL Queries
Example 2: Auditing SaveChanges
Final Thoughts

A Brief History of EF Core Interceptors

EF Core interceptors were first introduced in EF Core 3.0 (released in September 2019). This version marked a significant step forward in EF Core's extensibility, allowing developers to intercept low-level database operations like commands, connections, and transactions.

Since then, Microsoft has expanded interceptor capabilities in newer versions:

EF Core 5.0: Introduced SaveChanges interceptors for tracking changes at the context level.

EF Core 6.0+: Continued performance improvements and better support for asynchronous interception.

What Are EF Core Interceptors?

In Entity Framework Core (EF Core), interceptors allow developers to hook into the execution pipeline of EF Core's operations. Think of them as middleware for your database interactions. You can intercept events such as:

SQL command execution
Connection opening/closing
Transactions
SaveChanges lifecycle

This lets you inject custom logic like logging, auditing, validation, or performance metrics without modifying your application’s core logic.

EF Core Interceptors and the Decorator Pattern

EF Core interceptors are a real-world application of the Decorator Pattern, a classic design pattern where functionality is wrapped around existing behavior to extend or alter it.

The core EF operation is the base object.
Your interceptor is the decorator.
You add behavior before or after EF Core’s operation — without altering EF’s core.

This approach promotes clean code, separation of concerns, and makes your custom behavior reusable and testable.

Top Use Cases for EF Core Interceptors

– SQL Query Logging

– Track database queries for performance or debugging.

– Auditing – Automatically log user actions and timestamps.

– Soft Deletes – Intercept delete commands and convert them to updates.

– Command Modification – Change or enrich raw SQL before execution.

– Multi-Tenant Filtering – Inject filters dynamically for multi-tenant scenarios.

Example 1: Logging SQL Queries

Let’s log every SQL command executed by EF Core.

Step 1: Create a SQL Logging Interceptor

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Diagnostics;

public class SqlLoggingInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, 
        CommandEventData eventData, 
        InterceptionResult<DbDataReader> result)
    {
        Debug.WriteLine($"SQL Executed: {command.CommandText}");
        return base.ReaderExecuting(command, eventData, result);
    }
}

Output:

SQL Executed: SELECT * FROM [Users] WHERE [IsActive] = 1

Step 2: Register the Interceptor

public class AppDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder
            .UseSqlServer("YourConnectionString")
            .AddInterceptors(new SqlLoggingInterceptor());
    }
}

Example 2: Auditing SaveChanges

Let’s implement automatic auditing of entity modifications.

Step 1: Define an Auditable Entity Base Class

public abstract class AuditableEntity
{
    public DateTime ModifiedAt { get; set; }
    public string ModifiedBy { get; set; }
}

Step 2: Implement a SaveChangesInterceptor

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly string _currentUser;

    public AuditInterceptor(string currentUser)
    {
        _currentUser = currentUser;
    }

    public override int SavingChanges(DbContextEventData eventData, int result)
    {
        var context = eventData.Context;
        if (context == null) return base.SavingChanges(eventData, result);

        var entries = context.ChangeTracker
            .Entries<AuditableEntity>()
            .Where(e => e.State == EntityState.Modified);

        foreach (var entry in entries)
        {
            entry.Entity.ModifiedAt = DateTime.UtcNow;
            entry.Entity.ModifiedBy = _currentUser;
        }

        return base.SavingChanges(eventData, result);
    }
}

Final Thoughts

EF Core interceptors are an underutilized gem in the .NET ecosystem. They let you cleanly implement cross-cutting concerns without muddying your core application code. And because they follow the Decorator Pattern, you get flexibility, maintainability, and testability.

Whether you need to log queries, audit changes, enforce soft deletes, or handle custom behavior, interceptors offer a powerful and elegant solution.

References
EF Core Documentation – Interceptors
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors

EF Core 3.0 Release Notes (Interceptors introduced)
https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/whatsnew

EF Core SaveChanges Interceptor Docs
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors#savechanges-interception

Decorator Pattern - Refactoring Guru (for pattern explanation)
https://refactoring.guru/design-patterns/decorator

EF Core GitHub Repository (for latest updates and issues)
https://github.com/dotnet/efcore

EF Core: Lazy Loading, Eager Loading, and Loading Data on Demand

Thu, 06 Mar 2025 16:31:00 +0000

When working with Entity Framework Core (EF Core), there are different strategies for loading related data from the database.

So, how do you load a collection or other related objects?

Here are the main options:

1️⃣ Eager Loading (Include)

Loads related data immediately with the main entity using .Include().

Example: Load an Order with its Customer

var order = context.Orders
    .Include(o => o.Customer) // Load related Customer
    .First();

Example: Load a Customer with Their Orders

var customer = context.Customers
    .Include(c => c.Orders) // Load related Orders
    .First();

✅Pros:

✔ Avoids multiple database queries (N+1 problem)

✔ Simple and easy to use

❌ Cons:

❌ Can load unnecessary data, increasing query size

❌ Slower if you load too many relationships

2️⃣ Explicit Loading (Entry().Reference() / Entry().Collection())

Loads related data on demand (manually) using .Entry().

Example: Load a Single Related Entity

var order = context.Orders.First();

// Load related Customer manually
context.Entry(order).Reference(o => o.Customer).Load();

Console.WriteLine(order.Customer.Name);

Example: Load a Collection of Related Entities

var customer = context.Customers.First();

// Load related Orders manually
context.Entry(customer).Collection(c => c.Orders).Load();

Console.WriteLine($"Orders count: {customer.Orders.Count}");

✅ Pros:

✔ More control over when data is loaded

✔ Avoids unnecessary queries

❌ Cons:

❌ Requires additional queries

❌ Must remember to load data explicitly

3️⃣ Lazy Loading (Requires Proxies)

Loads related data only when accessed.

Install :

dotnet add package Microsoft.EntityFrameworkCore.Proxies

Steps to Enable Lazy Loading

Enable in DbContext:

protected override void OnConfiguring(DbContextOptionsBuilder options)
{
    options.UseLazyLoadingProxies().UseSqlite("Data Source=mydb.db");
}

Make navigation properties virtual

public virtual Customer Customer { get; set; } = default!;
public virtual List<Order> Orders { get; set; } = new();

Example Usage :

var order = context.Orders.First();

// Lazy loaded automatically when accessed

Console.WriteLine(order.Customer.Name);

✅ Pros:

✔ Simplifies code (data is loaded automatically)

✔ Works without modifying queries

❌ Cons:

❌ Requires proxies (extra package)

❌ Can lead to multiple database hits (N+1 problem)

4️⃣ Projection (Select with Anonymous Types)

Loads only specific data instead of full entities.

Example: Load Only Needed Fields

var orders = context.Orders
    .Select(o => new 
    { 
        o.OrderNumber, 
        CustomerName = o.Customer.Name 
    })
    .ToList();

foreach (var order in orders)
{
    Console.WriteLine($"{order.OrderNumber} - {order.CustomerName}");
}

✅ Pros:

✔ Best for performance (loads only required fields)

✔ Reduces unnecessary data transfer

❌ Cons:

❌ Cannot track entities (only works for read-only queries)

Summary Table

Best Practices
Use Eager Loading (Include()) when related data is always needed.

Use Explicit Loading if you want manual control.

Use Lazy Loading only if necessary (it can cause performance issues).

Use Projection (Select) when you need only some fields.

Source Code

You can find the complete source code for this tutorial at:
GitHub Repository

Here are some useful references to learn more about EF Core :

Official Microsoft Documentation
Entity Framework Core Loading Related Data
https://learn.microsoft.com/en-us/ef/core/querying/related-data

Covers Eager Loading, Explicit Loading, and Lazy Loading with examples.
EF Core: Configuring Lazy Loading
https://learn.microsoft.com/en-us/ef/core/querying/related-data/lazy

Explains how to enable Lazy Loading with proxies.
EF Core: Using Include() for Eager Loading
https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager

Details how to use .Include() and .ThenInclude().
EF Core Performance Considerations
https://learn.microsoft.com/en-us/ef/core/performance/

Best practices for optimizing queries and avoiding performance issues like N+1 queries.

Community & Blog Articles
EF Core Lazy Loading vs. Eager Loading - Which One Should You Use?
https://www.thinktecture.com/en/entity-framework-core/lazy-loading-vs-eager-loading/

A detailed comparison of when to use each strategy.
EF Core Best Practices: Avoiding Performance Pitfalls
https://www.michalbialecki.com/2020/11/29/entity-framework-core-performance-best-practices/

Covers when to use .Include(), lazy loading, and projection.

EF Core Global Query Filters: A Complete Guide

Sun, 02 Mar 2025 09:42:51 +0000

Entity Framework Core (EF Core) Global Query Filters allow you to apply filters to queries at the model level so that they automatically apply to all queries involving a specific entity.

This is particularly useful for scenarios like soft deletes, multi-tenancy, and user-based data filtering.

What is a Global Query Filter?

A global filter is a LINQ predicate that applies automatically to all queries on a specific entity type.

This means that any time you query the database, EF Core applies the filter implicitly, reducing the need for adding Where clauses manually.

Use Cases

Soft Deletes – Automatically filter out entities where IsDeleted =
true.
Multi-Tenancy – Ensure that a tenant only accesses their own data.
User-Based Filtering – Restrict users to see only their own records.

How to Define a Global Query Filter

Global filters are defined in the OnModelCreating method inside the DbContext class using the HasQueryFilter method.

Example : Soft Delete Implementation ..

public class BaseEntity
{
    public bool IsDeleted { get; set; }
}

public class Product : BaseEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>()
            .HasQueryFilter(p => !p.IsDeleted);
    }
}

Now, every query on Products automatically filters out records where IsDeleted = true.

Querying Products

var products = context.Products.ToList(); // Implicitly applies "WHERE IsDeleted = 0"

Bypassing the Global Filter

You can explicitly disable the filter using .IgnoreQueryFilters().

var allProducts = context.Products.IgnoreQueryFilters().ToList();

Applying Filters Dynamically (Multi-Tenancy Example)

public class AppDbContext : DbContext
{
    private readonly int _tenantId;

    public AppDbContext(DbContextOptions<AppDbContext> options, ITenantProvider tenantProvider)
        : base(options)
    {
        _tenantId = tenantProvider.GetTenantId();
    }

    public DbSet<Order> Orders { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>()
            .HasQueryFilter(o => o.TenantId == _tenantId);
    }
}

Now, EF Core automatically filters records based on _tenantId.

Limitations and Considerations

Filters do not apply to raw SQL queries (FromSqlRaw).
Navigation properties respect global filters (e.g., if Order has OrderDetails, the filter applies to them too).
Ensure filters do not cause unexpected performance issues on large datasets.
You can define multiple query filters per entity.

Combining Multiple Filters

modelBuilder.Entity<Product>()
    .HasQueryFilter(p => !p.IsDeleted)
    .HasQueryFilter(p => p.Status == "Active");

This results in:

SELECT * FROM Products WHERE IsDeleted = 0 AND Status = 'Active'

Disabling All Global Filters

You can disable all filters for a specific context query using:

context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

var allOrders = context.Orders.IgnoreQueryFilters().ToList();

Conclusion
EF Core’s Global Query Filters help enforce consistent rules across queries without adding redundant Where clauses. They are a powerful feature for soft deletes, multi-tenancy, and user-based access control. However, they should be used carefully, considering potential performance impacts.

Source Code

You can find the complete source code for this tutorial at:
GitHub Repository

Here are some useful references to learn more about EF Core Global Query Filters and Soft Delete:

Official EF Core Documentation
Global Query Filters
https://learn.microsoft.com/en-us/ef/core/querying/filters

Entity Framework Core SQLite Provider
https://learn.microsoft.com/en-us/ef/core/providers/sqlite/

Managing Data with EF Core
https://learn.microsoft.com/en-us/ef/core/

Community Articles & Tutorials
EF Core: Global Query Filters for Soft Deletes
https://www.thinktecture.com/en/entity-framework-core/global-query-filters/

Implementing Soft Delete in EF Core
https://medium.com/swlh/soft-delete-in-entity-framework-core-6c6b7a9784c7

Using SQLite with EF Core in Console Applications
https://code-maze.com/using-sqlite-with-entity-framework-core/

When to Use AsSplitQuery() in EF.core

Wed, 26 Feb 2025 08:10:09 +0000

When working with Entity Framework Core (EF Core), queries that involve multiple Include() statements can result in a single large query with multiple joins. This can cause performance issues due to data duplication and increased memory usage.

What is AsSplitQuery()?

AsSplitQuery() tells EF Core to fetch related data using separate SQL queries instead of one large join query. This helps optimize performance for complex queries.

Step 1: Setup Your Model

Let’s create a simple e-commerce scenario with Order, Customer, and OrderItem entities.

public class Order
{
    public int Id { get; set; }
    public string OrderNumber { get; set; }
    public Customer Customer { get; set; }
    public List<OrderItem> OrderItems { get; set; } = new();
}

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class OrderItem
{
    public int Id { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
}

Step 2: Configure the Database Context

We define our DbContext to include the necessary DbSet properties.

public class AppDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<Customer> Customers { get; set; }
    public DbSet<OrderItem> OrderItems { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlite("Data Source=app.db");
    }
}

Step 3: Query Without AsSplitQuery()

Let's say we want to fetch orders with their customers and order items.

**var orders = await _context.Orders
    .Include(o => o.Customer)
    .Include(o => o.OrderItems)
    .ToListAsync();**

What Happens Here?
EF Core generates a single SQL query with multiple JOIN operations.
If there are many orders and items, this can cause performance issues due to data duplication.

Step 4: Optimize with AsSplitQuery()

Now, let's improve performance by using AsSplitQuery().

var orders = await _context.Orders
    .Include(o => o.Customer)
    .Include(o => o.OrderItems)
    .AsSplitQuery() // Fetches data using multiple queries instead of joins
    .ToListAsync();

What Happens Now?

EF Core executes multiple separate SQL queries instead of a single large join.
Less memory is used since duplicate data is avoided.
Performance is improved when dealing with large datasets.

Step 5: Understanding the SQL Queries

Without AsSplitQuery()
EF Core runs one big SQL query:

SELECT o.*, c.*, oi.*
FROM Orders o
LEFT JOIN Customers c ON o.CustomerId = c.Id
LEFT JOIN OrderItems oi ON o.Id = oi.OrderId;

This may lead to repetitive customer data for each order item.

With AsSplitQuery()
EF Core runs separate queries:

SELECT * FROM Orders;
SELECT * FROM Customers WHERE Id IN (...);
SELECT * FROM OrderItems WHERE OrderId IN (...);

This reduces duplication and improves performance.

When to Use AsSplitQuery()

✅ Use AsSplitQuery() when:

You include multiple navigation properties (Include()).
You experience performance issues with large datasets.
You want to avoid data duplication.

❌ Avoid AsSplitQuery() when:

Your queries are already small and fast.
Your database round trips increase due to multiple queries.

Conclusion

Using AsSplitQuery() in EF Core can boost performance and reduce memory usage when working with complex queries. It’s a simple yet powerful optimization that can make your applications more efficient.

Coder Legion - Recent posts tagged ef

🚀 EF Core Query Optimization for Beginners

1. Use AsNoTracking() for Read-Only Queries ⭐

Benefits

2. Filter Data Before Loading It

3. Project Only What You Need

4. Don't Use Include() When Projecting

5. Sort in SQL

6. Project Child Collections

7. Use Async Queries

8. Create Proper Database Indexes

Final Optimized Query

🎯 Key Takeaways

Additional Resources

5 EF Core Features Every Enterprise Developer Should Know

1. Connection Resiliency and Retry Policies

2. Optimistic Concurrency Control

3. Performance Optimization with Compiled Queries

4. Transactions and Unit of Work

5. Global Query Filters

Final Thoughts

When IDbContextFactory enters the chat, and what it actually fixes.

When IDbContextFactory enters the chat, and what it actually fixes

What problems show up

What IDbContextFactory changes

When to use it

The takeaway

Reliable Messaging in .NET: Domain Events and the Outbox Pattern with EF Core Interceptors

Introduction

⚙️ A Quick Look at Entity Framework Core

What Are Interceptors?

The Problem

The Outbox Pattern (In a Nutshell)

The Architecture

Domain Events

⚙️ Capturing Events with an EF Core Interceptor

The Outbox Dispatcher

Why Use an Interceptor?

Benefits of the Outbox Pattern

References

✨ Closing Thoughts

Author

Supercharging EF Core Specifications with EF.CompileQuery

⚔️ The Mighty MERGE: Using SQL Merge Statements Safely with EF Core

Optimistic vs. Pessimistic Concurrency in EF Core (with Table Hints)

EF Core Bulk Updates and Deletes: Performance vs Change Tracking

EF Core Interceptors: Supercharge Your Data Access with the Decorator Pattern

A Brief History of EF Core Interceptors

EF Core: Lazy Loading, Eager Loading, and Loading Data on Demand

EF Core Global Query Filters: A Complete Guide

When to Use AsSplitQuery() in EF.core

What is AsSplitQuery()?

Step 1: Setup Your Model

Step 2: Configure the Database Context

Step 3: Query Without AsSplitQuery()

Step 4: Optimize with AsSplitQuery()

Step 5: Understanding the SQL Queries

Conclusion

1. Use `AsNoTracking()` for Read-Only Queries ⭐

4. Don't Use `Include()` When Projecting

When `IDbContextFactory` enters the chat, and what it actually fixes

What `IDbContextFactory` changes