ASP.NET Core中仓储层与服务层职责边界划分咨询

你的现有实现思路存在明显设计缺陷，既没有做到真正的关注点分离，还会引入严重的性能问题，先明确两层的硬边界，再给你对应场景的正确实现方式。

两层核心职责边界 #

• 仓储层：只做数据持久化抽象，完全不承载任何业务语义。核心作用是对上层屏蔽ORM、数据库的实现细节，提供通用、无业务含义的数据读写能力，比如通用CRUD、基于表达式的过滤查询、事务提交等。仓储层的逻辑不会随业务规则变化而修改，除非你更换数据存储方案。
• 服务层：承载所有业务逻辑、流程编排。负责参数校验、业务规则判断、查询条件组装、跨仓储/跨实体操作编排、事务控制、DTO转换等，所有和业务需求直接相关的逻辑都收敛在这一层。

你当前方案的问题 #

你设计的Get<T>(Expression<Func<List<T>, List<T>>>)方法有两个致命问题：

1. 入参是基于内存集合List<T>的表达式，意味着执行查询时会先把对应表的全量数据加载到内存中再做过滤，完全浪费了EF Core的SQL翻译能力，数据量稍大就会出现接口超时、内存占用过高的问题。
2. 分层只是形式上的：你把过滤逻辑从仓储移到了服务层，但本质上仓储对传入的逻辑没有任何管控能力，后续要做全局软删除过滤、查询缓存、数据权限拦截等通用能力时，根本无法统一处理。

指定作者特定年份书籍查询场景的正确拆分 #

第一步：实现合理的泛型仓储基础能力 #

泛型仓储只提供无业务含义的通用数据访问方法，注意返回/接收的是可被EF Core翻译为SQL的表达式树，不要直接操作内存集合：

public interface IRepository<T> where T : class
{
    Task<T?> GetByIdAsync(long id, CancellationToken ct = default);
    Task AddAsync(T entity, CancellationToken ct = default);
    void Update(T entity);
    void Delete(T entity);
    // 基于表达式的列表查询，条件由上层传入
    Task<List<T>> GetListAsync(Expression<Func<T, bool>> predicate, CancellationToken ct = default);
    // 如需做复杂查询拼接，可返回IQueryable，由上层组装查询后再执行
    IQueryable<T> Query();
}

// 泛型仓储实现
public class Repository<T> : IRepository<T> where T : class
{
    private readonly AppDbContext _dbContext;
    private readonly DbSet<T> _dbSet;

    public Repository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
        _dbSet = dbContext.Set<T>();
    }

    public async Task<List<T>> GetListAsync(Expression<Func<T, bool>> predicate, CancellationToken ct = default)
    {
        // 这里可以统一追加全局过滤规则，比如软删除过滤、租户数据隔离等
        return await _dbSet.Where(predicate).ToListAsync(ct);
    }

    public IQueryable<T> Query()
    {
        return _dbSet.AsQueryable();
    }

    // 其余接口实现省略
}

第二步：在服务层承载所有业务逻辑 #

服务层注入对应仓储，完成参数校验、业务规则判断、查询条件组装，再调用仓储完成数据读取：

public class BookService
{
    private readonly IRepository<Book> _bookRepository;

    public BookService(IRepository<Book> bookRepository)
    {
        _bookRepository = bookRepository;
    }

    public async Task<List<BookDto>> GetAuthorBooksInYearAsync(long authorId, int publishYear, CancellationToken ct)
    {
        // 业务参数校验全放在服务层
        if (authorId <= 0) throw new ArgumentException("作者ID非法");
        if (publishYear < 0 || publishYear > DateTime.UtcNow.Year) throw new ArgumentException("出版年份非法");

        // 业务查询条件由服务层组装，传给仓储执行
        var books = await _bookRepository.GetListAsync(
            b => b.AuthorId == authorId && b.PublishYear == publishYear,
            ct
        );

        // DTO转换、额外业务加工（比如填充书籍标签、统计信息）都在这层完成
        return books.Adapt<List<BookDto>>();
    }
}

补充实践建议 #

• 不要为了分层而分层：如果你的项目规模很小、业务逻辑简单，完全可以省去仓储层，直接在服务层注入DbContext操作，硬套分层只会增加不必要的代码复杂度。
• 涉及多实体关联的复杂查询（比如联查作者、书籍、评论数据），不要拆成多次仓储调用在内存中拼接，直接通过仓储暴露的IQueryable用EF Core的Include/ThenInclude组装联查逻辑，由EF Core生成高效的联表SQL即可。
• 仓储层绝对不能出现任何业务判断逻辑，比如不要在仓储里写“如果年份大于2000就加某个过滤条件”这类和业务规则绑定的代码，这类逻辑必须全部收敛到服务层。
• 如果项目中存在大量可复用的查询条件，可以引入规约模式把公共查询逻辑封装成规约对象，由服务层传入规约给仓储执行，避免重复写相同的过滤表达式。

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