仓储模式下作用域实例变更共享问题及独立实例创建方案

你的问题核心是同一作用域内的MyDbContext是单例实例，两个泛型仓储共享这个上下文，当第一个仓储的操作触发异常时，上下文的变更跟踪器中已经存在处于错误状态的实体（比如未通过验证的Person），后续使用同一个上下文的审计日志操作会因为这些脏数据的存在而失败。

下面是三种可行的解决方案：

方案1：为审计日志创建独立的服务作用域 #

在catch块中重新创建一个全新的ServiceScope，从这个独立作用域中获取审计仓储实例。由于每个作用域对应独立的DbContext，新的仓储不会受到之前上下文的错误状态影响。

try
{
    using (var serviceScope = _serviceProvider.CreateScope())
    {
        var personDataService = serviceScope.ServiceProvider.GetRequiredService<IGenericRepository<Person, MyDbContext>>();
        // 执行Person插入操作
        personDataService.Insert(new Person { /* 可能缺少Name字段导致异常 */ });
        await personDataService.SaveChangesAsync();
    }
}
catch (SqlException ex)
{
    // 创建独立作用域处理审计日志
    using (var auditScope = _serviceProvider.CreateScope())
    {
        var auditLogDataService = auditScope.ServiceProvider.GetRequiredService<IGenericRepository<AuditLog, MyDbContext>>();
        auditLogDataService.Insert(new AuditLog 
        { 
            ErrorMessage = ex.Message, 
            OccurredAt = DateTime.UtcNow 
        });
        await auditLogDataService.SaveChangesAsync();
    }
}

优点：完全符合依赖注入的设计原则，能复用Program.cs中配置的DbContext选项，无需重复代码，是最推荐的方案。

方案2：手动创建独立的DbContext实例 #

如果不想依赖作用域，可以直接实例化一个全新的MyDbContext，再手动创建审计仓储。这种方式绕过DI，直接控制上下文的生命周期。

// 需要注入IConfiguration获取连接字符串
private readonly IConfiguration _configuration;
private const string connectionName = "YourConnectionStringName";

// 构造函数注入IConfiguration
public YourWorkerService(IServiceProvider serviceProvider, IConfiguration configuration)
{
    _serviceProvider = serviceProvider;
    _configuration = configuration;
}

try
{
    // 原Person操作代码...
}
catch (SqlException ex)
{
    // 手动创建独立的DbContext
    var dbOptions = new DbContextOptionsBuilder<MyDbContext>()
        .UseSqlServer(_configuration.GetConnectionString(connectionName))
        .Options;
    
    using (var independentContext = new MyDbContext(dbOptions))
    {
        var auditRepository = new GenericRepository<AuditLog, MyDbContext>(independentContext);
        auditRepository.Insert(new AuditLog 
        { 
            ErrorMessage = ex.Message, 
            OccurredAt = DateTime.UtcNow 
        });
        await independentContext.SaveChangesAsync();
    }
}

优点：完全独立于原作用域，适合简单场景；缺点：需要重复配置DbContext选项，无法复用DI中注册的其他DbContext扩展（比如拦截器）。

方案3：清理DbContext的变更跟踪状态 #

如果必须在同一个作用域内处理，可以清除DbContext变更跟踪器中的所有实体，消除之前操作的影响。但这种方式风险较高，不推荐作为首选。

try
{
    using (var serviceScope = _serviceProvider.CreateScope())
    {
        var personDataService = serviceScope.ServiceProvider.GetRequiredService<IGenericRepository<Person, MyDbContext>>();
        // 执行Person插入操作...
        await personDataService.SaveChangesAsync();
    }
}
catch (SqlException ex)
{
    using (var serviceScope = _serviceProvider.CreateScope())
    {
        var dbContext = serviceScope.ServiceProvider.GetRequiredService<MyDbContext>();
        // 清除所有被跟踪的实体
        dbContext.ChangeTracker.Clear();
        
        var auditLogDataService = serviceScope.ServiceProvider.GetRequiredService<IGenericRepository<AuditLog, MyDbContext>>();
        auditLogDataService.Insert(new AuditLog 
        { 
            ErrorMessage = ex.Message, 
            OccurredAt = DateTime.UtcNow 
        });
        await auditLogDataService.SaveChangesAsync();
    }
}

优点：无需额外作用域；缺点：可能存在隐藏的状态残留（比如未被跟踪的变更、事务状态），容易引发其他未知问题。

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