Audit.NET 中解决 DbContext 依赖注入问题的实践指南

问题背景

在使用 Audit.NET 进行审计日志记录时，开发者经常需要在 Entity Framework 审计配置中使用自定义的 DbContext。然而，直接使用 UseDbContext<T>() 方法可能会遇到"Constructor on type 'DbContext' not found"的错误。

核心问题分析

这个问题的根源在于 Audit.NET 的配置阶段与 ASP.NET Core 依赖注入生命周期的冲突。当我们在 Startup.ConfigureServices 方法中配置 Audit.NET 时，服务提供者尚未完全构建完成，此时尝试解析 DbContext 会导致异常。

解决方案

方法一：延迟配置到 Configure 方法

将 Audit.NET 的配置移到 Startup.Configure 方法中，此时应用已经完成服务注册：

public void Configure(IApplicationBuilder app)
{
    Audit.Core.Configuration.Setup()
        .UseEntityFramework(x => x
            .UseDbContext(ev => app.ApplicationServices.GetService<ApplicationDbContext>()));
}

方法二：创建独立的作用域

当需要解析作用域服务时，可以显式创建新的作用域：

Audit.Core.Configuration.Setup()
    .UseEntityFramework(ef => ef
        .UseDbContext(ev => 
            app.ApplicationServices.CreateScope()
                .ServiceProvider.GetRequiredService<ApplicationDbContext>())
        .DisposeDbContext());

高级应用：访问请求作用域服务

在审计实体操作中，有时需要访问当前请求的作用域服务（如用户上下文）。可以通过已解析的 DbContext 获取其他服务：

.AuditEntityAction<Auditable>((ev, entry, entity) =>
{
    var requestContext = ev.GetEntityFrameworkEvent()
                         .GetDbContext()
                         .GetService<IRequestContext>();
    // 使用requestContext填充审计字段
})

最佳实践建议

1. 配置时机：推荐在 Configure 方法中进行 Audit.NET 配置，确保服务提供者可用
2. 作用域管理：使用 CreateScope() 创建独立作用域时，记得调用 DisposeDbContext() 确保资源释放
3. 服务解析：优先通过已解析的 DbContext 获取其他服务，保持作用域一致性
4. 性能考虑：避免在审计配置中频繁创建新作用域，考虑缓存常用服务

总结

通过合理利用 ASP.NET Core 的依赖注入系统和 Audit.NET 提供的扩展方法，我们可以优雅地解决审计日志记录中的 DbContext 依赖问题。关键在于理解不同配置阶段的服务可用性，并选择适当的服务解析策略。