仓储模式是.NET中用于分离业务逻辑与数据访问的抽象层,通过定义如IUserRepository接口并结合依赖注入,实现对数据访问的具体技术解耦;业务逻辑仅依赖接口,可通过SqlUserRepository等具体实现操作数据库,而无需知晓底层细节;该模式提升可维护性、支持单元测试、降低耦合,并可配合Unit of Work模式管理事务,适用于需保持业务逻辑清晰独立的中大型项目。

.NET中的仓储模式(Repository Pattern)是一种设计模式,用于在业务逻辑层和数据访问层之间建立一个抽象层。它的核心目标是将数据访问逻辑从业务代码中分离出来,从而实现解耦、提高可维护性,并便于单元测试。
什么是仓储模式?
仓储模式本质上是一个中间层,它向业务逻辑提供一个类似集合的接口来操作领域对象,而不需要关心底层数据是如何存储或获取的。比如你可以调用 userRepository.GetAll() 或 userRepository.Add(user),就像操作内存中的列表一样,但背后可能是数据库查询或写入操作。
在 .NET 中,通常通过定义接口和具体实现类来应用这一模式:
public interface IUserRepository
{
User GetById(int id);
void Add(User user);
void Update(User user);
void Delete(int id);
}
public class SqlUserRepository : IUserRepository
{
private readonly AppDbContext _context;
public SqlUserRepository(AppDbContext context)
{
_context = context;
}
public User GetById(int id) => _context.Users.Find(id);
public void Add(User user) => _context.Users.Add(user);
// 其他实现...
}
如何实现业务逻辑与数据访问的解耦?
通过依赖注入和接口抽象,可以彻底切断业务服务对具体数据访问技术的依赖。
- 使用接口定义契约:业务逻辑只依赖于 IUserRepository 接口,不关心它是 SQL Server 实现、内存模拟还是其他数据库。
- 依赖注入容器注册实现:在 ASP.NET Core 的 Startup 或 Program 文件中注册服务:
builder.Services.AddScoped();
- 在服务中通过构造函数注入:业务类无需创建仓储实例,由框架自动注入。
public class UserService
{
private readonly IUserRepository _userRepository;
public UserService(IUserRepository userRepository)
{
_userRepository = userRepository;
}
public User GetUserProfile(int userId)
{
return _userRepository.GetById(userId)
?? throw new InvalidOperationException("用户不存在");
}
}
这样,如果将来更换数据库或使用不同的持久化方式(如 MongoDB 或 REST API),只需提供新的仓储实现,而无需修改业务逻辑代码。
带来的好处
- 易于测试:在单元测试中可以用内存仓储或 Mock 对象替代真实数据库,快速验证逻辑。
- 降低耦合度:业务层不绑定到 Entity Framework 或 Dapper 等具体技术。
- 代码更清晰:数据访问集中管理,避免在控制器或服务中直接写 DbContext 调用。
- 支持多数据源:不同实体可使用不同仓储,灵活应对复杂系统架构。
配合 Unit of Work 模式更好用
当多个仓储需要共享同一个数据库事务时,可以引入 Unit of Work 模式,统一提交更改。
public interface IUnitOfWork
{
IUserRepository Users { get; }
IOrderRepository Orders { get; }
int Commit(); // 保存所有变更
}
这样能确保数据一致性,尤其是在涉及多个表的操作中。
基本上就这些。仓储模式不是必须的,但在中大型项目中非常有用,尤其当你希望保持业务逻辑干净、独立且可测试时。










