如何在HostedService创建的StateMachine实例中正确依赖注入Entity Framework Core的ApplicationDbContext

我来帮你梳理下这个场景下的解决方案，核心要解决的是单例生命周期的StateMachine如何安全使用Scoped生命周期的DbContext，同时还要封装逻辑避免重复代码。

问题根源 #

你的StateMachine是单例（因为存在StateMachineHost的List中，而Host是单例），但ApplicationDbContext默认是Scoped生命周期——如果直接把DbContext注入到StateMachine里，会导致整个应用生命周期复用同一个DbContext实例，引发并发问题、数据不一致等风险。所以必须保证每次数据库访问都用全新的DbContext实例。

方案1：给StateMachine注入IServiceScopeFactory，封装数据库访问逻辑 #

最直接的方式是让StateMachine持有IServiceScopeFactory，每次需要访问数据库时，创建一个新的Scope来获取DbContext和Repository，用完自动释放。

第一步：修改StateMachine的构造函数

public class StateMachine
{
    private readonly IServiceScopeFactory _scopeFactory;

    // 注入IServiceScopeFactory，用于创建临时Scope
    public StateMachine(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }
}

第二步：在StateMachine中封装数据库操作方法

把创建Scope、获取DbContext/Repository的逻辑封装在方法里，避免重复编写：

public async Task HandleWebApiTriggeredWork(int itemId)
{
    // 每次操作创建独立Scope，保证DbContext是全新的
    using var scope = _scopeFactory.CreateScope();
    var dbContext = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();
    var itemRepository = new ItemRepository(dbContext);

    // 执行具体业务逻辑
    var targetItem = await itemRepository.GetByIdAsync(itemId);
    // ... 其他操作
}

// 定时器触发的操作同理
public async Task HandleTimerTriggeredWork()
{
    using var scope = _scopeFactory.CreateScope();
    var itemRepository = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();
    var items = await itemRepository.GetPendingItemsAsync();
    // ... 批量处理逻辑
}

方案2：优化依赖注入，将Repository注册为Scoped服务 #

上面的方案里手动new了ItemRepository，其实可以把Repository注册为Scoped服务，让DI容器来管理它的生命周期，进一步解耦：

第一步：在Program/Startup中注册Repository

// 注册为Scoped，和DbContext生命周期一致
services.AddScoped<IItemRepository, ItemRepository>();

第二步：修改StateMachine的数据库操作方法

public async Task HandleWebApiTriggeredWork(int itemId)
{
    using var scope = _scopeFactory.CreateScope();
    // 直接从Scope中获取已注册的Repository
    var itemRepository = scope.ServiceProvider.GetRequiredService<IItemRepository>();

    var targetItem = await itemRepository.GetByIdAsync(itemId);
    // ... 业务逻辑
}

方案3：抽象数据库操作服务，进一步解耦StateMachine #

如果StateMachine的业务逻辑和数据库操作耦合度高，可以把数据库相关的逻辑抽成一个专门的Scoped服务，让StateMachine只关注状态流转，数据库操作交给专门的服务处理：

第一步：定义数据库操作服务接口和实现

public interface IStateMachineDbService
{
    Task ProcessItemAsync(int itemId);
    Task ProcessPendingItemsAsync();
}

public class StateMachineDbService : IStateMachineDbService
{
    private readonly IItemRepository _itemRepository;

    // 直接注入Scoped的Repository，DI会自动处理DbContext
    public StateMachineDbService(IItemRepository itemRepository)
    {
        _itemRepository = itemRepository;
    }

    public async Task ProcessItemAsync(int itemId)
    {
        var item = await _itemRepository.GetByIdAsync(itemId);
        // ... 具体数据库操作
    }

    public async Task ProcessPendingItemsAsync()
    {
        var items = await _itemRepository.GetPendingItemsAsync();
        // ... 批量处理
    }
}

第二步：注册这个服务

services.AddScoped<IStateMachineDbService, StateMachineDbService>();

第三步：StateMachine中调用服务

public async Task HandleWebApiTriggeredWork(int itemId)
{
    using var scope = _scopeFactory.CreateScope();
    var dbService = scope.ServiceProvider.GetRequiredService<IStateMachineDbService>();
    await dbService.ProcessItemAsync(itemId);
}

关键注意事项 #

• 绝对不要在StateMachine中保存DbContext、Repository或Scoped服务的实例，必须每次使用时从新的Scope中获取，用完随Scope一起释放。
• 定时器触发的操作同样要遵循这个规则——在定时器回调方法内部创建Scope，不要在回调外部持有Scoped服务。
• 利用using var scope的语法糖，确保Scope自动释放，避免资源泄漏。

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