在依赖注入构造函数中实例化IQueryable<T>是否为最佳实践？

结论：构造函数中初始化带谓词的IQueryable并非良好实践 #

核心问题有两点：

• 延迟执行引发的上下文失效风险：IQueryable是延迟执行的，构造函数中赋值的query会绑定到构造时刻的仓储上下文（比如EF Core的DbContext）。如果仓储上下文是Scoped生命周期（这是常见配置），当类实例存活超过上下文生命周期时，后续调用这个query会触发上下文已释放的异常。
• 状态共享导致的意外Bug：如果后续方法对类成员query追加额外查询条件（如Where、OrderBy），这些修改会永久改变成员状态。下次其他方法复用query时，会带上之前追加的条件，导致不符合预期的查询结果。

更妥当的实现方式 #

方式1：封装基础查询方法，每次使用时调用 #

把基础谓词逻辑封装成私有方法，每次查询时调用该方法获取全新查询链，避免状态共享：

private readonly IRepository<T> _repo;

public SomeClass(IRepository<T> repo)
{
    _repo = repo;
}

// 封装排除已删除数据的基础查询逻辑
private IQueryable<T> GetActiveEntitiesQuery()
{
    return _repo.GetQueryable().Where(c => !c.IsDeleted);
}

// 业务方法中复用基础查询
public List<T> GetActiveEntitiesByName(string name)
{
    return GetActiveEntitiesQuery()
           .Where(c => c.Name.Contains(name))
           .ToList();
}

方式2：在仓储层封装基础查询逻辑 #

如果排除已删除数据是全局通用规则，可以直接在仓储层新增方法统一实现，上层代码无需重复编写谓词：

// 仓储接口新增方法
public interface IRepository<T>
{
    IQueryable<T> GetQueryable();
    IQueryable<T> GetActiveQueryable(); // 封装排除已删除的逻辑
}

// 仓储实现
public class Repository<T> : IRepository<T>
{
    private readonly DbContext _context;

    public Repository(DbContext context)
    {
        _context = context;
    }

    public IQueryable<T> GetQueryable()
    {
        return _context.Set<T>();
    }

    public IQueryable<T> GetActiveQueryable()
    {
        return GetQueryable().Where(c => !c.IsDeleted);
    }
}

// 业务类中直接调用封装后的方法
public SomeClass(IRepository<T> repo)
{
    _repo = repo;
}

public List<T> GetActiveEntitiesByName(string name)
{
    return _repo.GetActiveQueryable()
           .Where(c => c.Name.Contains(name))
           .ToList();
}

这两种方式既保证了基础查询逻辑的复用，又规避了构造函数初始化IQueryable带来的上下文和状态问题。

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