ASP.NET Core & EF Core实现Unit of Work：DbContextFactory vs DbContext选型

我计划自行实现Unit of Work模式来管控功能规划（尽管EF Core的DbContext本身已具备工作单元特性），现在需要明确：在工作单元的构造函数中，使用DbContextFactory还是直接注入DbContext实例哪种方案更优，以及具体原因。

代码示例 #

使用DbContextFactory #

public sealed class UnitOfWork : IUnitOfWork
{
    private AppDbContext _dbContext;
    
    public UnitOfWork(IContextFactory contextFactory)
    {
        _dbContext = contextFactory.DbContext;
    }
}

直接注入DbContext #

public sealed class UnitOfWork : IUnitOfWork
{
    private AppDbContext _dbContext;
    
    public UnitOfWork(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }
}

方案对比与选型建议 #

直接注入DbContext的适用场景与优缺点 #

• 优点：
  • 实现简单，无需额外编写工厂类，代码简洁直观。
  • ASP.NET Core默认DI容器会自动管理DbContext的生命周期（默认Scoped，每个请求对应一个实例），无需手动处理创建与释放。
  • 完美契合常规Web请求场景：一个请求对应一个工作单元，事务边界与请求生命周期对齐。
• 缺点：
  • 灵活性不足：无法在同一个请求中创建多个独立的工作单元（比如需要同时处理多个互不干扰的事务），因为整个请求周期内只有一个DbContext实例。
  • 非请求场景受限：在后台任务、定时器等脱离Http请求的场景中，Scoped生命周期的DbContext无法直接获取，容易引发生命周期管理问题。

使用DbContextFactory的适用场景与优缺点 #

• 优点：
  • 灵活性极强：可以按需创建独立的DbContext实例，每个实例对应一个独立的工作单元/事务，完美支持多事务并行处理的场景。
  • 适配非请求场景：在后台任务、批量处理等场景中，能主动控制DbContext的创建与释放时机，避免生命周期冲突。
  • 职责分离更彻底：明确由工厂负责DbContext的实例化，工作单元只专注于事务与数据操作的管控。
• 缺点：
  • 需要额外实现工厂类，增加了代码复杂度。
  • 若工厂未自动处理DbContext的释放，需手动调用Dispose，否则可能导致数据库连接泄漏。

结论 #

• 如果你的应用以常规Web请求为主，每个请求对应一个工作单元，直接注入DbContext是最优选择，简单高效且符合框架默认的生命周期管理。
• 如果需要处理多事务并行、后台任务，或者需要灵活控制DbContext生命周期的场景，DbContextFactory是更合适的方案，能提供足够的扩展性与控制力。

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