仓储模式（Repository Pattern）在.NET中真的能实现松耦合吗？

首先要明确：松耦合不等于零耦合，它的核心是把耦合限制在抽象契约层，而非具体实现层，以此降低修改带来的影响范围。你觉得修改时还要动其他项目，可能是混淆了「核心契约变更」和「实现细节变更」的区别，下面分场景拆解：

1. 不同修改场景的耦合影响 #

（1）修改领域类 #

领域类是业务模型的核心，本身就会被仓储、业务层依赖——但仓储模式已经把「领域类的业务逻辑」和「数据持久化逻辑」解耦了。比如你修改了Product类的Price属性类型，只需要调整仓储层的映射配置（比如EF的Fluent API），不需要修改业务层的逻辑代码；如果没有仓储模式，你可能要在所有直接操作数据库的业务代码里改SQL或ORM调用。

（2）修改接口契约 #

仓储接口是稳定的业务契约，设计时就应该遵循「开闭原则」，不会随便修改。如果真的需要变更（比如把GetById(int id)改成GetById(Guid id)），这属于核心契约的变更，确实需要同步修改实现类和调用方——但这是设计问题，不是仓储模式的锅。仓储模式的作用是让这种变更只影响「接口的实现者」和「直接依赖接口的上层」，而不是扩散到整个系统。

（3）修改数据访问层（DAL） #

这才是仓储模式+DI发挥松耦合价值的核心场景：

• 比如你原来用EF Core实现仓储，现在要换成Dapper，只要新的Dapper实现类继承同一个仓储接口，业务层、UI层完全不需要修改任何代码，只需要在DI容器里替换注册的实现即可。
• 再比如你要从SQL Server换成MySQL，同样只需要调整仓储层的数据库连接和实现细节，上层代码完全无感。

2. 代码示例对比 #

硬耦合（无仓储+DI） #

// 业务层直接依赖EF Core的具体实现
public class ProductService
{
    private readonly AppDbContext _dbContext;
    public ProductService(AppDbContext dbContext) => _dbContext = dbContext;

    public Product GetProduct(int id)
    {
        return _dbContext.Products.FirstOrDefault(p => p.Id == id);
    }
}

此时换Dapper，业务层必须全量修改。

松耦合（仓储+DI） #

// 抽象仓储接口（契约）
public interface IProductRepository
{
    Product GetById(int id);
}

// EF Core实现
public class EfProductRepository : IProductRepository
{
    private readonly AppDbContext _dbContext;
    public EfProductRepository(AppDbContext dbContext) => _dbContext = dbContext;

    public Product GetById(int id)
    {
        return _dbContext.Products.FirstOrDefault(p => p.Id == id);
    }
}

// Dapper实现
public class DapperProductRepository : IProductRepository
{
    private readonly IDbConnection _connection;
    public DapperProductRepository(IDbConnection connection) => _connection = connection;

    public Product GetById(int id)
    {
        return _connection.QueryFirstOrDefault<Product>(
            "SELECT * FROM Products WHERE Id = @Id", 
            new { Id = id }
        );
    }
}

// 业务层依赖抽象接口
public class ProductService
{
    private readonly IProductRepository _repo;
    public ProductService(IProductRepository repo) => _repo = repo;

    public Product GetProduct(int id)
    {
        return _repo.GetById(id);
    }
}

此时换实现，只需要修改DI注册代码：

// 原来注册EF实现
services.AddScoped<IProductRepository, EfProductRepository>();
// 换成Dapper实现
services.AddScoped<IProductRepository, DapperProductRepository>();

业务层代码完全不用动，这就是松耦合的直观体现。

总结 #

仓储模式+DI的本质是让上层依赖抽象，而非具体实现：

• 实现细节的修改（比如换ORM、换数据库）不会影响上层；
• 核心契约（领域类、仓储接口）的变更确实需要同步调整，但仓储模式已经把这种变更的影响范围降到了最小，而非完全消除——毕竟系统不可能完全无耦合，松耦合的目标是「可控的耦合」。

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