AddDbContext与AddDbContextFactory的区别及Blazor项目适用场景

核心疑问解答 #

1. 什么场景下应该使用AddDbContextFactory而非AddDbContext？ #

• Blazor Server/Blazor WebAssembly 全场景，组件生命周期与常规ASP.NET Core请求作用域不匹配，直接注入Scoped DbContext极易触发并发操作冲突
• 需要在同一个作用域内执行多个并行EF Core操作（如同时发起多个异步查询）的场景
• 需要手动控制DbContext生命周期，不想交由DI容器自动管理释放的场景
• 后台任务、定时任务等无常规请求作用域的场景

2. 通过DbContextFactory创建的DbContext与通过AddDbContext注册的DbContext，生命周期有什么差异？ #

• 调用AddDbContext默认注册的DbContext为Scoped生命周期，由DI容器全权管理：同一个作用域内（ASP.NET Core默认对应单次HTTP请求）所有注入位置拿到的是同一个实例，作用域销毁时自动释放上下文。
• 调用IDbContextFactory.CreateDbContext()创建的DbContext不归DI容器管理，生命周期完全由开发者控制：每次调用都会返回全新的实例，使用完成后需要手动调用Dispose/DisposeAsync释放，或者用using块包裹自动释放。

注：调用AddDbContextFactory时会额外注册一个Scoped生命周期的DbContext，该实例和AddDbContext注册的逻辑完全一致，是为了方便在匹配Scoped作用域的场景下直接注入使用，和工厂创建的实例无关联。
你示例代码中通过工厂创建的DbContext不属于Scoped生命周期，不会被DI容器自动回收。

3. Blazor项目是否应该统一使用DbContextFactory？ #

是，这是微软官方明确推荐的Blazor项目最佳实践。
Blazor Server的组件存活在SignalR连接对应的会话周期中，远长于单次HTTP请求的作用域，直接注入Scoped DbContext时，同一个用户的多次操作触发EF Core调用很容易出现并行操作报错。Blazor WebAssembly即使运行在客户端单例环境下，多组件同时访问DbContext也会存在并发风险，统一通过工厂创建独立上下文实例、每个操作使用单独上下文的方案，可以完全规避并发冲突问题。

4. 创建Scoped生命周期的DbContext是否会产生额外内存开销？ #

开销极低可忽略不计。DbContext本身被设计为轻量级对象，官方测试验证过创建和释放的性能开销非常小，除非是短时间内高频创建数千上万个实例的极端场景，否则不会产生可感知的内存或性能损耗。反而为了节省这点可忽略的开销复用同一个DbContext实例，可能导致的并发报错、内存泄漏（上下文长期跟踪大量无用实体）等问题，负面影响要严重得多。

额外补充 #

你提到的“多线程或并发访问DbContext时是否必须用AddDbContextFactory”的问题，答案是肯定的。DbContext本身不是线程安全的，并发场景下必须保证每个线程/每个并行操作使用独立的DbContext实例，工厂已经封装好了所有DbContext的配置（连接字符串、拦截器等），是最便捷的创建独立实例的方案，不需要手动传入配置参数重复初始化。

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