.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<IUserRepository, SqlUserRepository>();在服务中通过构造函数注入：业务类无需创建仓储实例，由框架自动注入。
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(); // 保存所有变更
}
这样能确保数据一致性，尤其是在涉及多个表的操作中。
基本上就这些。仓储模式不是必须的，但在中大型项目中非常有用，尤其当你希望保持业务逻辑干净、独立且可测试时。
![C# 如何从 URL 下载文件_C# URL 文件下载实现指南](httpClient.GetByteArrayAsync("https://example.com/image.jpg "C# 如何从 URL 下载文件_C# URL 文件下载实现指南")
