如何协调EF Core的SavingChanges与SaveChanges拦截器/事件追踪已保存实体

一、协调SavingChanges与SavedChanges的核心思路 #

要解决两个触发点的协调问题，核心是在保存前缓存变更实体，保存完成后用缓存执行入队，避免依赖保存后的跟踪状态：

• 缓存变更实体：在SavingChanges阶段（保存操作执行前），从ChangeTracker中筛选出Added/Modified状态的实体，存入当前拦截器实例的私有缓存集合。这个阶段实体处于跟踪状态，能完整获取所有变更信息。
• 执行后处理：在SavedChanges阶段（保存操作成功完成后），遍历缓存的实体执行入队操作，执行完毕后清空缓存，避免重复处理。
• 自动容错：如果保存操作失败（比如事务回滚），SavedChanges不会触发，缓存的实体也不会被处理，自然避免了无效入队。

二、自定义作用域拦截器实现代码 #

1. 编写拦截器类 #

public class EntityPostProcessingInterceptor : SaveChangesInterceptor
{
    private readonly List<EntityEntry> _pendingChanges = new();
    private readonly IMessageQueueService _messageQueue;

    // 注入消息队列服务，用于实体入队
    public EntityPostProcessingInterceptor(IMessageQueueService messageQueue)
    {
        _messageQueue = messageQueue;
    }

    // 保存前捕获变更实体
    public override ValueTask<InterceptionResult<int>> SavingChangesAsync(
        DbContextEventData eventData,
        InterceptionResult<int> result,
        CancellationToken cancellationToken = default)
    {
        if (eventData.Context is not null)
        {
            var trackedChanges = eventData.Context.ChangeTracker.Entries()
                .Where(e => e.State is EntityState.Added or EntityState.Modified)
                .ToList();
            _pendingChanges.AddRange(trackedChanges);
        }
        return base.SavingChangesAsync(eventData, result, cancellationToken);
    }

    // 保存完成后执行入队
    public override async ValueTask<int> SavedChangesAsync(
        SaveChangesCompletedEventData eventData,
        int result,
        CancellationToken cancellationToken = default)
    {
        foreach (var entry in _pendingChanges)
        {
            // 根据业务需求处理实体，比如序列化后入队
            await _messageQueue.EnqueueEntityAsync(entry.Entity);
        }
        _pendingChanges.Clear();
        return await base.SavedChangesAsync(eventData, result, cancellationToken);
    }
}

2. 注册拦截器为作用域服务 #

// 在Program.cs中注册，确保每个请求/租户DbContext对应独立的拦截器实例
builder.Services.AddScoped<EntityPostProcessingInterceptor>();

3. 在DbContext中绑定拦截器 #

public class TenantDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        // 从服务容器获取作用域内的拦截器，添加到DbContext拦截器集合
        var interceptor = this.GetService<EntityPostProcessingInterceptor>();
        if (interceptor != null)
        {
            optionsBuilder.AddInterceptors(interceptor);
        }
        // 多租户动态连接字符串配置逻辑...
    }
}

三、拦截器生命周期与变更追踪的适配 #

• 单例拦截器：不适合多租户场景。因为单例实例会被所有请求/租户共享，缓存的变更会出现线程安全问题，无法隔离不同请求的变更数据。
• 作用域拦截器：推荐使用。每个请求（或每个DbContext实例）对应一个拦截器实例，缓存的变更完全隔离，完美适配多租户动态创建DbContext的需求，能可靠追踪每个请求内的实体变更。
• 瞬态拦截器：效果类似作用域，但作用域更贴合请求生命周期，能确保拦截器与DbContext实例的生命周期一致，避免不必要的实例创建。

四、对比事件方案的优势 #

如果使用DbContext的SavingChanges/SavedChanges事件，需要在每个DbContext实例创建时订阅事件，对于多租户动态创建DbContext的场景，代码侵入性更高。而拦截器通过作用域注册+全局绑定的方式，无需修改DbContext的创建逻辑，更符合集中处理的需求。

内容的提问来源于stack exchange，提问作者Carlos Draper Giggs