EF Core查询逻辑封装：对比仓储模式的价值与潜在风险问询

我最近了解到一种EF Core查询逻辑的封装方式，和常用的仓储模式有明显区别。

仓储模式示例 #

public interface ISomeRepo
{
    IEnumerable<string> GetAll();
    // 其他查询方法
}

public class SomeRepo : ISomeRepo
{
    public IEnumerable<string> GetAll()
    {
        // 从数据库获取数据的逻辑
    }
    // 其他查询方法的实现
}

单一查询类模式示例 #

这种模式将每个查询逻辑封装为独立的类，基于统一的查询接口：

public interface IModelQuery<out TResult, in TModel>
{
    IEnumerable<TResult> Execute(TModel model);
}

public class PartialMatchQuery : IModelQuery<string, IEnumerable<string>>
{
    private readonly string partial;
 
    public PartialMatchQuery(string partialString)
    {
        partial = partialString;
    }
 
    public IEnumerable<string> Execute(IEnumerable<string> model)
    {
        return model.Where(s => s.ToLower().Contains(partial));
    }
}

调用示例 #

static int Main(string[] args)
{
    var strings = new List<string>() // 为简化示例使用IEnumerable<T>实现类
            {
                "Abhc", "Bmhh", "Csjudsm", "Dsjuh", "Ejhduhb", "Fmjasgh"
            };

    var query = new PartialMatchQuery("m");
    var result = query.Execute(strings).ToList();

    return 0;
}

这种模式相比包含GetAll()、GetById()等固定方法的仓储模式更灵活，但存在“一个查询对应一个类”的问题，且缺乏实际落地案例参考。针对这一模式，我有两个技术问题：

问题1：承担“一个查询对应一个类”的成本，用这种模式替代仓储模式是否值得？ #

是否值得取决于项目的规模、查询复杂度和团队协作模式：

• 小型项目/简单查询场景：不值得。仓储模式的固定方法足够覆盖需求，类数量少、结构简单，学习和维护成本更低，没必要为了灵活性引入大量查询类。
• 大型项目/复杂多变的查询场景：值得。每个查询类遵循单一职责原则，逻辑独立，便于单元测试（可以轻松模拟输入数据源验证查询逻辑），也方便团队成员并行开发不同查询；如果后续查询逻辑需要修改，只需改动对应类，不会影响其他查询，降低了耦合风险。
• 查询复用率的考量：如果某个查询逻辑会在多个地方复用，封装为独立类能避免代码重复；但如果是一次性的简单查询，单独建类反而增加冗余。

问题2：这种模式是否存在未注意到的、影响可维护性或扩展性的副作用？ #

确实存在一些容易被忽略的问题：

• 类爆炸导致结构臃肿：随着查询数量增加，项目中会出现大量命名类似的查询类，增加了查找和管理成本，新人上手需要花费更多时间熟悉结构。
• 依赖注入的负担：如果使用依赖注入容器管理这些查询类，需要注册大量服务，配置繁琐；如果查询类需要依赖其他服务（比如日志、配置），注入逻辑会进一步复杂化。
• 重复逻辑难以复用：多个查询类如果存在相似的过滤、排序逻辑，容易出现代码冗余，需要额外抽象出公共逻辑（比如基础查询基类、扩展方法），否则维护成本会上升。
• EF Core特性的适配问题：如果直接传入IEnumerable<T>而非IQueryable<T>，会导致查询在内存中执行，失去EF Core的SQL优化能力；另外，这种模式和Unit of Work的整合不如仓储模式自然，事务管理需要额外设计。
• 调试复杂度提升：排查查询问题时，需要定位到具体的查询类，相比在仓储类中找对应方法，路径更长。

内容的提问来源于stack exchange，提问作者Zombies are Real