如何实现不受LINQ转换操作影响的IQueryable<T>元素拦截？

嗨，我完全懂你现在的头疼点——想在仓库返回的IQueryable迭代时拦截元素做跟踪，但一加OrderBy这类LINQ操作就崩溃，总不能为了兼容各种LINQ返回类型去实现一堆接口吧？其实不用搞复杂的QueryProvider包装，这里有几个更省心的思路：

方案一：只拦截枚举环节，不碰QueryProvider #

问题出在你之前的QueryProviderWrapper每次都返回QueryableWrapper，但像OrderBy这类方法返回的是IOrderedQueryable<T>，你的包装类没实现这个接口，自然会类型转换失败。

换个思路：不要包装整个QueryProvider，只在最终迭代的时候拦截元素。我们写一个轻量的IQueryable<T>实现，只重写GetEnumerator()，复用原始查询的Provider和Expression，这样后续所有LINQ操作都由原始Provider处理，返回正确的类型，只有迭代时才触发拦截逻辑。

代码示例： #

// 自定义Queryable，仅处理枚举拦截
internal class TrackedQueryable<T> : IQueryable<T>
{
    private readonly IQueryable<T> _sourceQuery;
    private readonly Action<T> _elementTrackingAction;

    public TrackedQueryable(IQueryable<T> source, Action<T> trackAction)
    {
        _sourceQuery = source;
        _elementTrackingAction = trackAction;
    }

    // 直接复用原始查询的核心属性
    public Type ElementType => _sourceQuery.ElementType;
    public Expression Expression => _sourceQuery.Expression;
    public IQueryProvider Provider => _sourceQuery.Provider;

    // 只重写枚举器，实现拦截
    public IEnumerator<T> GetEnumerator()
    {
        return new TrackedEnumerator<T>(_sourceQuery.GetEnumerator(), _elementTrackingAction);
    }

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

// 包装枚举器，在MoveNext时触发跟踪逻辑
internal class TrackedEnumerator<T> : IEnumerator<T>
{
    private readonly IEnumerator<T> _sourceEnumerator;
    private readonly Action<T> _trackAction;

    public TrackedEnumerator(IEnumerator<T> source, Action<T> trackAction)
    {
        _sourceEnumerator = source;
        _trackAction = trackAction;
    }

    public T Current => _sourceEnumerator.Current;
    object? IEnumerator.Current => Current;

    public void Dispose() => _sourceEnumerator.Dispose();

    public bool MoveNext()
    {
        bool hasNext = _sourceEnumerator.MoveNext();
        if (hasNext)
        {
            var currentElement = _sourceEnumerator.Current;
            // 这里加入你的判断和跟踪逻辑
            if (currentElement is IDomainEntity domainObject)
            {
                _trackAction(currentElement);
                Console.WriteLine($"已跟踪领域对象：{domainObject.GetType().FullName}");
            }
        }
        return hasNext;
    }

    public void Reset() => _sourceEnumerator.Reset();
}

// 写个扩展方法，方便仓库调用
public static class QueryableTrackingExtensions
{
    public static IQueryable<T> WithElementTracking<T>(this IQueryable<T> source, Action<T> trackAction)
    {
        return new TrackedQueryable<T>(source, trackAction);
    }
}

仓库里的用法： #

public IQueryable<T> GetDomainQuery<T>() where T : class
{
    var baseQuery = _dbContext.Set<T>().AsQueryable();
    // 直接返回带跟踪拦截的Queryable，后续LINQ操作完全不受影响
    return baseQuery.WithElementTracking(elem => 
    {
        // 这里替换成你的实际跟踪逻辑，比如加入自定义跟踪管理器
        _domainObjectTracker.Track(elem);
    });
}

这个方案的好处是：所有LINQ操作（OrderBy、Where、Skip等）都由原始的QueryProvider处理，返回正确的类型（比如IOrderedQueryable<T>），只有当调用ToList()、foreach迭代时才会触发我们的拦截逻辑，完全避开了接口兼容的坑。

方案二：如果用EF Core，直接用内置ChangeTracker #

如果你的领域对象是EF Core的实体，其实根本不用自己写包装——EF Core默认会自动跟踪查询出来的实体（除非你加了AsNoTracking()）。ChangeTracker会自动监控实体的修改，你可以通过它来实现“防止修改”的需求，比如：

// 查询后获取所有被跟踪的实体
var trackedEntities = _dbContext.ChangeTracker.Entries<IDomainEntity>();
// 可以设置实体为只读，或者监听修改事件
foreach (var entry in trackedEntities)
{
    entry.State = EntityState.Unchanged; // 强制标记为未修改，防止意外保存
    // 或者监听PropertyChanged事件
    entry.Entity.PropertyChanged += (sender, e) => 
    {
        throw new InvalidOperationException("领域对象不允许直接修改，请使用领域方法！");
    };
}

这种方式完全复用EF的现有机制，不用自己写任何包装代码，省心又可靠。

总结 #

如果你不需要在QueryProvider层面做拦截，只是想在迭代元素时跟踪，方案一是最轻便的选择，既避开了复杂的接口实现，又能兼容所有LINQ操作；如果是EF环境，优先用方案二的内置功能，减少自定义代码的维护成本。

内容的提问来源于stack exchange，提问作者Peter Morris