为何在依赖注入中优先注入完整DbContext而非仅所需DbSet？

这问题问得特别好——我刚接触EF Core的时候也纠结过这个点：明明注入单个DbSet<T>看起来更“精准”，能直接从构造函数看出依赖的数据，为啥大家却普遍选择注入完整的DbContext呢？其实背后藏着不少实际开发里的考量：

• DbContext不止是DbSet的容器
  DbContext的核心职责远不止提供DbSet，它还管着事务管理、实体变更追踪、关联关系处理这些关键逻辑。比如你现在的DoStuff只查MyType，但哪天需求变了，要在同一个操作里更新MyType和关联的OtherType，或者需要开启事务保证操作原子性，这时候单个DbSet根本搞不定，必须依赖DbContext的完整能力。

• DI配置的维护成本
  如果每个服务都要注入对应的DbSet，你得在依赖注入容器里逐个注册每个DbSet<T>——想想看，要是项目里有十几个实体，光注册DbSet就得写一堆重复代码。而注册一次DbContext就能覆盖所有实体，后续新增实体也不用改DI配置，维护起来省心太多。

• EF Core的设计导向
  DbContext本身就是EF框架的核心抽象，官方文档、示例教程几乎全是用注入DbContext的方式。开发者们跟着官方最佳实践走，自然就形成了行业常态。毕竟没人愿意特意去搞一套和官方背离的方案，除非有特别强的理由。

• 应对需求变化的灵活性
  现在你的类只用到MyType，但需求是随时可能变的。如果一开始注入的是DbContext，后续要用到其他实体，直接在代码里调用dbContext.OtherType就行，不用改构造函数、不用改DI注册，也不用动测试代码。但如果注入的是DbSet<MyType>，那每加一个新依赖都得改一圈，成本太高。

• 单元测试的实际场景
  你提到注入DbSet在单元测试里更清晰，但实际上现在有很多成熟的方案可以轻松模拟DbContext：比如用EF Core自带的InMemory数据库，或者用Moq配合DbContext的测试替身，只需要配置你用到的DbSet就行。而且很多测试场景需要模拟的不只是查询，还有事务、变更追踪这些DbContext独有的功能，这时候模拟DbContext反而更贴近真实业务逻辑。

当然，这不是说注入DbSet完全不可行——如果你的服务确实只依赖单个实体，而且确定未来不会扩展，那这种方式也没问题。但这种场景在实际项目里比较少见，所以注入完整DbContext才会成为行业主流。

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