Repository Pattern已死？深入剖析.NET中的设计模式争议与最佳实践

郑子铭

发布于 2025-05-17 13:06:25

16900

代码可运行

文章被收录于专栏：DotNet NB && CloudNativeDotNet NB && CloudNative

运行总次数：0

代码可运行

一场激烈的技术辩论

在.NET生态中，鲜有话题能像 仓储模式（Repository Pattern） 这般引发激烈争论。有些开发者奉其为整洁架构的基石，另一些人则认为它是被Entity Framework Core（EF Core）淘汰的冗余设计。

那么，仓储模式真的消亡了吗？还是说它正在进化？本文将剖析正反双方观点，探讨其适用场景，并回答是否应在你的下一个.NET项目中采用它。

什么是仓储模式？

仓储模式是一种抽象数据访问的设计模式，旨在简化管理和测试。通过创建仓储类作为中间层，业务逻辑不再直接调用数据库。

典型的.NET仓储模式示例：

public interface IRepository<T> where T : class  
{  
    Task<T?> GetByIdAsync(int id);  
    Task<IEnumerable<T>> GetAllAsync();  
    Task AddAsync(T entity);  
    Task UpdateAsync(T entity);  
    Task DeleteAsync(T entity);  
}

基于Entity Framework Core的实现：

public classRepository<T> : IRepository<T> whereT : class
{  
    protectedreadonly DbContext _context;  
    protectedreadonly DbSet<T> _dbSet;  

    public Repository(DbContext context)
    {  
        _context = context;  
        _dbSet = context.Set<T>();  
    }  

    publicasync Task<T?> GetByIdAsync(int id) => await _dbSet.FindAsync(id);  
    publicasync Task<IEnumerable<T>> GetAllAsync() => await _dbSet.ToListAsync();  
    public async Task AddAsync(T entity) => await _dbSet.AddAsync(entity);  
    public async Task UpdateAsync(T entity) => _dbSet.Update(entity);  
    public async Task DeleteAsync(T entity) => _dbSet.Remove(entity);  
}

其核心目标？关注点分离、提升可测试性、解耦业务逻辑与数据库细节。

反对仓储模式：为何有人认为它已过时？

随着Entity Framework Core的普及，许多开发者认为仓储模式已冗余，原因如下：

1. EF Core已内置仓储模式与工作单元模式 EF Core提供开箱即用的功能： • 变更跟踪：无需手动调用Update() • 工作单元：自动管理事务 • 抽象层：通过LINQ和DbContext处理数据库交互

如果你的仓储只是简单包装DbContext，无异于重复造轮子。

2. 冗余抽象层 = 更高的复杂度 若仓储方法仅转发调用至DbContext，意义何在？

反面教材——无用的仓储类：

public class UserRepository  
{  
    private readonly AppDbContext _context;  
    public UserRepository(AppDbContext context) => _context = context;  

    public async Task<User?> GetUserByIdAsync(int id)  
    {  
        return await _context.Users.FindAsync(id);  
    }  
}

直接注入AppDbContext至服务层更简洁：

public class UserService  
{  
    private readonly AppDbContext _context;  
    public UserService(AppDbContext context) => _context = context;  

    public async Task<User?> GetUserByIdAsync(int id)  
    {  
        return await _context.Users.FindAsync(id);  
    }  
}

为何要添加冗余层？

3. 限制EF Core的完整能力 EF Core的Include()、AsNoTracking()和原生SQL等高级功能，可能在强制通过预定义仓储方法时失去灵活性。

支持仓储模式：为何它仍有生命力？

尽管争议不断，仓储模式在特定场景下仍不可替代。

1. 数据库独立性 若可能从SQL Server切换至MongoDB或PostgreSQL，抽象仓储可增强代码的未来适应性。

// 接口  
publicinterfaceIUserRepository
{  
    Task<User?> GetByIdAsync(int id);  
}  

// EF Core实现  
publicclassEfUserRepository : IUserRepository
{  
    privatereadonly AppDbContext _context;  
    public EfUserRepository(AppDbContext context) => _context = context;  
    publicasync Task<User?> GetByIdAsync(int id) => await _context.Users.FindAsync(id);  
}  

// MongoDB实现  
publicclassMongoUserRepository : IUserRepository
{  
    privatereadonly IMongoCollection<User> _users;  
    public MongoUserRepository(IMongoClient client)
    {  
        var database = client.GetDatabase("MyDatabase");  
        _users = database.GetCollection<User>("Users");  
    }  
    publicasync Task<User?> GetByIdAsync(int id)  
    {  
        returnawait _users.Find(u => u.Id == id).FirstOrDefaultAsync();  
    }  
}

切换数据库变得轻而易举。

2. 可测试性：更简单的单元测试 直接注入DbContext会因EF Core与内存数据库的兼容性问题导致单元测试困难。

通过仓储接口，可轻松模拟数据库层：

var mockRepo = new Mock<IUserRepository>();  
mockRepo.Setup(repo => repo.GetByIdAsync()).ReturnsAsync(new User { Id = , Name = "Ganesh Gurav" });  
var userService = new UserService(mockRepo.Object);  
var user = await userService.GetUserByIdAsync();  
Assert.Equal("Ganesh Gurav", user?.Name);

若无仓储，则需依赖更复杂、低效的集成测试。

3. 集中管理复杂查询 在大型应用中，涉及多表连接、聚合或原生SQL的查询，可通过仓储封装以保持服务层整洁。

public class UserRepository : IUserRepository  
{  
    private readonly AppDbContext _context;  
    public UserRepository(AppDbContext context) => _context = context;  

    public async Task<IEnumerable<User>> GetUsersWithOrdersAsync()  
    {  
        return await _context.Users.Include(u => u.Orders).ToListAsync();  
    }  
}

避免LINQ查询散落各处，降低维护成本。