EF Core与ASP.NET Core中仓储及工作单元模式的适用性疑问

嘿，这个问题在EF社区里一直是个热门讨论点，我来给你拆解清楚～

为什么不同版本教程的观点差异这么大？ #

核心原因在于EF本身的迭代进化：

• 在EF 5那个阶段，EF的依赖注入支持还不完善，DbContext的可测试性很差，Mock起来麻烦重重。这时候仓储+工作单元模式是非常实用的解决方案——它能把EF的具体实现封装起来，让业务层只依赖抽象接口，方便替换成测试用的假实现（比如内存集合），同时统一管理事务逻辑。
• 而到了EF Core时代（尤其是Core 2.0之后），EF Core原生支持依赖注入，DbContext天然就是一个工作单元（它的SaveChanges方法就是事务提交的入口），DbSet也具备了仓储的基本CRUD能力。再加上EF Core提供了InMemory数据库、SQLite内存库等轻量级测试方案，Mock DbSet也变得简单很多。所以很多现代文章会认为，额外套一层仓储/工作单元属于过度设计，反而增加冗余代码，完全没必要。

仓储+工作单元模式的适用场景 #

虽然EF Core已经足够强大，但在以下场景中，这个模式依然能发挥独特价值：

• 需要完全抽象数据访问层：如果你的项目未来有可能替换ORM（比如从EF Core换成Dapper、NHibernate），或者需要同时支持多种数据源，仓储模式能彻底把业务逻辑和具体数据访问技术解耦，替换实现时不用修改业务代码。
• 复杂业务的事务统一管理：当你的业务逻辑需要跨多个DbContext操作，或者需要和其他非EF的数据操作（比如Redis、第三方API）放在同一个事务里时，自定义的工作单元可以整合这些操作，实现统一的事务控制。
• 精细化的测试需求：如果你的单元测试需要完全脱离EF的环境（比如不想依赖InMemory数据库的特性限制），仓储模式能让你用纯内存集合轻松模拟数据访问层，测试逻辑更纯粹。
• 大型团队的规范统一：在多人协作的大型项目中，仓储模式可以统一数据访问的规范，避免不同开发者写出风格迥异的EF查询，同时封装通用的CRUD和复杂查询逻辑，提升代码一致性和可维护性。

不建议使用的场景 #

如果你的项目是小型应用，或者只是简单的CRUD业务，那额外引入仓储+工作单元就是画蛇添足——直接使用DbContext和DbSet会更简洁，减少不必要的代码层级。

补充一句：其实EF Core的DbContext本身就是工作单元模式的实现，DbSet则是仓储的一种简化形式，所以很多时候我们是在“重复造轮子”，这也是现在很多教程不推荐该模式的核心原因。

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