使用EF Core实现仓储模式，无需编写大量重复方法

1. 这种实现方式是否常规？ #

这种为每个查询场景编写专属仓储方法的做法很常见，但绝非最优。很多团队刚开始引入仓储模式时，容易把所有查询逻辑一股脑塞进仓储类，导致仓储变成臃肿的"查询垃圾桶"——不仅违背单一职责原则，还会让后续维护成本急剧上升（比如30个实体+大量API，很快就会出现几百个仓储方法）。

2. 最佳实践建议 #

- 拆分职责：基础仓储 + 领域查询服务 #

• 基础仓储：只封装通用CRUD逻辑（比如泛型IRepository<T>，包含Add/Update/Delete/GetById/GetQueryable等），专注于数据的基础操作，不涉及业务查询。
• 领域查询服务：按业务领域拆分（比如UserQueryService、OrderQueryService），专门处理该领域的复杂查询、关联数据加载、聚合计算等场景。每个服务对应前端的一类数据需求，职责清晰，便于维护。

- 充分利用EF Core原生特性 #

• 用Include/ThenInclude处理关联数据加载，避免手动编写Join逻辑；
• 直接用LINQ的Select做DTO投影，只返回前端需要的字段，减少数据库传输量和内存开销；
• 复杂聚合或SQL逻辑，优先用FromSqlRaw/SqlQuery直接执行原生SQL，或用EF Core的LINQ聚合函数（Count/Sum等），不要强行封装成仓储方法。

- 避免过度封装 #

EF Core本身已经实现了仓储+工作单元模式的核心能力，过度封装会屏蔽它的灵活性（比如延迟加载、编译查询、全局筛选等特性）。不要试图把所有EF Core的能力都包装成仓储方法，让领域服务直接通过仓储暴露的IQueryable<T>来构建查询，反而更高效。

3. 用表达式实现泛型化减少方法编写 #

完全可以通过泛型+表达式树来复用通用查询逻辑，避免重复编写相似的仓储方法。以下是核心实现思路：

泛型仓储基础结构 #

// 泛型仓储接口
public interface IRepository<T> where T : class
{
    IQueryable<T> GetQueryable();
    Task<T?> GetByIdAsync(int id);
    Task AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(T entity);
}

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

    public Repository(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public IQueryable<T> GetQueryable() => _dbContext.Set<T>();

    public async Task<T?> GetByIdAsync(int id) => await _dbContext.Set<T>().FindAsync(id);

    public async Task AddAsync(T entity) => await _dbContext.Set<T>().AddAsync(entity);

    public void UpdateAsync(T entity) => _dbContext.Set<T>().Update(entity);

    public void DeleteAsync(T entity) => _dbContext.Set<T>().Remove(entity);
}

扩展方法实现通用查询逻辑 #

通过扩展方法封装过滤、排序、投影、关联加载等通用逻辑，让领域服务可以灵活组合：

public static class RepositoryExtensions
{
    // 带过滤、排序、投影的通用查询方法
    public static async Task<List<TResult>> QueryAsync<T, TResult>(
        this IRepository<T> repository,
        Expression<Func<T, bool>>? filter = null,
        Func<IQueryable<T>, IOrderedQueryable<T>>? orderBy = null,
        Expression<Func<T, TResult>> projection)
        where T : class
    {
        var query = repository.GetQueryable();
        
        if (filter != null)
            query = query.Where(filter);
        
        if (orderBy != null)
            query = orderBy(query);
        
        return await query.Select(projection).ToListAsync();
    }

    // 通用关联加载方法
    public static IQueryable<T> Include<T, TProperty>(
        this IRepository<T> repository,
        Expression<Func<T, TProperty>> includeExpression)
        where T : class
    {
        return repository.GetQueryable().Include(includeExpression);
    }
}

领域服务中的使用示例 #

public class UserQueryService
{
    private readonly IRepository<User> _userRepository;

    public UserQueryService(IRepository<User> userRepository)
    {
        _userRepository = userRepository;
    }

    // 获取带订单统计的用户列表
    public async Task<List<UserStatsDto>> GetUserStatsAsync()
    {
        return await _userRepository
            .Include(u => u.Orders)
            .QueryAsync(
                projection: u => new UserStatsDto
                {
                    UserId = u.Id,
                    UserName = u.Name,
                    TotalOrders = u.Orders.Count(),
                    TotalAmount = u.Orders.Sum(o => o.Amount)
                },
                orderBy: q => q.OrderByDescending(u => u.Orders.Count()));
    }

    // 根据条件过滤用户
    public async Task<List<UserDto>> GetFilteredUsersAsync(string keyword)
    {
        return await _userRepository.QueryAsync(
            filter: u => u.Name.Contains(keyword) || u.Email.Contains(keyword),
            projection: u => new UserDto { Id = u.Id, Name = u.Name, Email = u.Email });
    }
}

这种方式既保留了EF Core的灵活性，又通过泛型和表达式树减少了重复代码，同时让业务查询逻辑归位到领域服务中，避免仓储类臃肿。

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