.NET Core实现仓储时DbContextPool与DbContextFactory选型及测试问题

疑问逐个解答 #

1. DbContextPool方案的实例获取问题 #

你不需要也不应该直接注入DbContextPool<TContext>实例，这是EF Core的内部实现类，没有公开的手动获取实例的API。如果要使用上下文池的能力，官方的正确用法是注册时调用AddPooledDbContextFactory<MyDbContext>()，之后注入IDbContextFactory<MyDbContext>，调用CreateDbContext()时EF Core会自动从池中获取复用的实例，你手动new MyDbContext()创建的实例不会走池逻辑，完全浪费池的性能优化效果。

2. 直接伪造MyDbContext的场景与实现 #

实际开发中存在这类场景：

• 你的MyDbContext包含自定义方法、存储过程调用封装、或者自定义查询扩展，这类逻辑无法仅通过修改Options用内存数据库模拟
• 测试需要验证DbContext的特定成员是否被调用、或者模拟DbContext抛出特定异常的边界场景
  伪造方法：使用Moq、NSubstitute等Mock框架直接构造Mock<MyDbContext>对象，按需设置成员的返回值/行为即可。这种方式比修改Options更灵活，不需要依赖任何存储配置即可模拟各种极端场景。

3. DbContextFactory最优的判断是否正确 #

这个判断完全正确。IDbContextFactory<TContext>本身就是EF Core官方为短生命周期上下文场景设计的原生实现，完美匹配你每个仓储方法独立创建、销毁上下文的需求。而且上下文的创建逻辑完全由Factory的实现决定，你可以在测试时随意替换Factory的实现，返回内存配置的上下文、伪造的上下文都不需要修改仓储代码，解耦性非常好。

4. 同时支持两类测试的最优方案 #

方案2（DbContextFactory方案）是唯一可以完美覆盖两类测试需求的选择：

• 做仓储集成测试（连接mdf执行真实SQL）时，只需要给Factory配置对应mdf文件的连接字符串，即可创建真实连接的DbContext执行测试
• 做领域服务单元测试需要伪造仓储时，既可以直接MockIMyRepo接口完全不依赖DbContext，也可以给Factory配置内存数据库的Options返回内存上下文，还可以替换Factory实现返回伪造的DbContext实例，灵活性拉满。

落地实现建议 #

• 优先使用官方原生的IDbContextFactory<MyDbContext>，不要自己手写Factory实现，注册时如果需要池的性能优势，调用AddPooledDbContextFactory<MyDbContext>(opt => 配置连接逻辑)即可，兼顾性能和灵活性
• 仓储层只依赖IDbContextFactory<MyDbContext>，不要在仓储内部硬编码new MyDbContext()的逻辑，所有上下文创建逻辑全部交给DI容器注册的Factory实现，符合开闭原则
• 测试场景分层处理：
  • 仓储集成测试：直接使用配置了真实mdf连接的Factory，跑真实SQL校验结果
  • 领域服务单元测试：优先MockIMyRepo接口，减少对DbContext的依赖；如果需要模拟仓储的真实行为，给Factory配置内存数据库Options即可
• 不要使用方案1：把DbContextOptions注入仓储的做法相当于硬绑定了上下文的构造逻辑，后续要替换自定义DbContext派生类、加创建上下文的前置逻辑都需要修改仓储代码，可维护性差
• 不要使用方案3：直接依赖DbContextPool属于依赖内部实现，不符合EF Core的设计规范，后续版本升级极易出现兼容性问题

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