ASP.NET WebAPI中如何根据参数值动态添加依赖注入作用域？

首先，我完全理解你想避免在控制器里写一堆if/else的心情——这种动态服务解析的场景确实应该把逻辑集中在DI注册层面，而不是散落在业务代码里。你的思路方向是对的，但当前代码有两个核心问题导致动态注入没生效：

问题出在哪？ #

1. 中间件里的局部作用域和请求作用域完全隔离
   你在中间件里手动创建了一个scope，但这个作用域是独立于当前HTTP请求自带的作用域的。控制器和其他请求内的服务使用的是请求作用域，所以你在这个局部作用域里做的服务解析，对请求作用域没有任何影响，自然后续拿不到正确的实例。

2. 服务注册的方式和注入需求不匹配
   你注册的是Func<string, IAccountingUserService>，但如果控制器里直接注入IAccountingUserService，DI容器根本不知道该怎么解析它——因为你没直接注册这个接口的实现，只注册了一个工厂委托。

解决方案：让DI容器自动处理动态解析 #

下面是两种更符合ASP.NET Core DI设计原则的实现方式，你可以根据场景选择：

方案一：基于请求参数的Scoped服务注册（推荐）

这种方式把动态解析逻辑直接放到服务注册阶段，利用IHttpContextAccessor访问当前请求的路由参数，让DI容器自动为每个请求提供正确的服务实例。

1. 修改服务注册扩展方法

internal static void AddService<TInterface, TQuickBooksImplementation, TXeroImplementation>(IServiceCollection services)
    where TInterface : class
    where TQuickBooksImplementation : class, TInterface
    where TXeroImplementation : class, TInterface
{
    // 先注册两个具体实现（用Transient，因为无状态）
    services.AddTransient<TQuickBooksImplementation>();
    services.AddTransient<TXeroImplementation>();

    // 注册Scoped的接口实例，基于当前请求的路由参数
    services.AddScoped<TInterface>(serviceProvider =>
    {
        var httpContextAccessor = serviceProvider.GetRequiredService<IHttpContextAccessor>();
        var context = httpContextAccessor.HttpContext ?? 
            throw new InvalidOperationException("当前无可用的HTTP请求上下文");

        string accountingSystemTypeId = context.Request.RouteValues["accountingSystemTypeId"]?.ToString();
        if (string.IsNullOrEmpty(accountingSystemTypeId))
        {
            // 这里可以根据业务需求返回默认实现，或者抛出异常
            throw new ArgumentNullException(nameof(accountingSystemTypeId), "路由中缺少accountingSystemTypeId参数");
        }

        if (!Guid.TryParse(accountingSystemTypeId, out var systemTypeId))
        {
            throw new FormatException("accountingSystemTypeId不是有效的Guid格式");
        }

        return systemTypeId == AccountingSystemTypes.QuickAccountingSystemTypeId
            ? serviceProvider.GetRequiredService<TQuickBooksImplementation>()
            : serviceProvider.GetRequiredService<TXeroImplementation>();
    });
}

2. 在Startup.cs中注册必要服务
   别忘了注册IHttpContextAccessor，否则无法在Scoped工厂里访问请求上下文：

public void ConfigureServices(IServiceCollection services)
{
    // 注册HttpContext访问器
    services.AddHttpContextAccessor();
    
    // 注册你的动态服务
    StartupHelpers.AddService<IAccountingUserService, QuickBooksApiServices.AccountingUserService, XeroApiServices.AccountingUserService>(services);
    
    // 其他服务注册...
    services.AddControllers();
}

3. 控制器中直接注入接口
   现在你可以直接在控制器里注入IAccountingUserService，DI容器会自动根据当前请求的路由参数返回正确的实现，完全不需要写if/else：

[ApiController]
[Route("api/[controller]/{accountingSystemTypeId}")]
public class AccountingController : ControllerBase
{
    private readonly IAccountingUserService _accountingService;

    public AccountingController(IAccountingUserService accountingService)
    {
        _accountingService = accountingService;
    }

    [HttpGet("users")]
    public async Task<IActionResult> GetUsers()
    {
        var users = await _accountingService.GetUsersAsync();
        return Ok(users);
    }
}

方案二：中间件+HttpContext.Items存储实例

如果你的参数不是来自路由（比如来自请求头、Token），可以用这种方式：在中间件里解析好服务实例，存到HttpContext.Items，然后让DI容器从这里获取实例。

1. 修改中间件代码

public class AccountingServiceMiddleware
{
    private readonly RequestDelegate _next;

    public AccountingServiceMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context, IServiceProvider serviceProvider)
    {
        string accountingSystemTypeId = context.Request.RouteValues["accountingSystemTypeId"]?.ToString();
        if (!string.IsNullOrEmpty(accountingSystemTypeId))
        {
            // 用当前请求的作用域解析服务（不要创建新的scope！）
            var serviceResolver = serviceProvider.GetRequiredService<Func<string, IAccountingUserService>>();
            var accountingService = serviceResolver(accountingSystemTypeId);
            // 把实例存到HttpContext.Items，供后续使用
            context.Items[typeof(IAccountingUserService)] = accountingService;
        }

        // 继续执行请求管道
        await _next(context);
    }
}

2. 更新服务注册扩展方法

internal static void AddService<TInterface, TQuickBooksImplementation, TXeroImplementation>(IServiceCollection services)
    where TInterface : class
    where TQuickBooksImplementation : class, TInterface
    where TXeroImplementation : class, TInterface
{
    services.AddTransient<TQuickBooksImplementation>();
    services.AddTransient<TXeroImplementation>();

    // 注册工厂委托
    services.AddTransient<Func<string, TInterface>>(serviceProvider => accountsystemTypeId =>
    {
        if (!Guid.TryParse(accountsystemTypeId, out var systemTypeId))
            throw new FormatException("无效的系统类型ID");

        return systemTypeId == AccountingSystemTypes.QuickAccountingSystemTypeId
            ? serviceProvider.GetService<TQuickBooksImplementation>()
            : serviceProvider.GetService<TXeroImplementation>();
    });

    // 注册Scoped接口，从HttpContext.Items获取实例
    services.AddScoped<TInterface>(serviceProvider =>
    {
        var httpContextAccessor = serviceProvider.GetRequiredService<IHttpContextAccessor>();
        var context = httpContextAccessor.HttpContext;
        
        if (context == null || !context.Items.TryGetValue(typeof(TInterface), out var service))
        {
            throw new InvalidOperationException("服务实例未在中间件中初始化");
        }

        return (TInterface)service;
    });
}

3. 在Startup.cs中注册中间件
   要确保中间件在控制器之前执行，所以放在UseRouting之后，UseEndpoints之前：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // 其他中间件...
    
    app.UseRouting();

    // 注册你的中间件
    app.UseMiddleware<AccountingServiceMiddleware>();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

最后总结几个最佳实践 #

1. 不要手动创建与请求无关的作用域：ASP.NET Core会为每个HTTP请求自动创建一个Scoped作用域，手动创建的独立作用域和请求上下文完全隔离，无法被控制器使用。
2. 集中管理动态解析逻辑：把服务解析逻辑放在DI注册阶段或中间件，不要散落在控制器里，保持业务代码的干净。
3. 参数校验要提前做：在服务解析阶段就处理无效参数的情况，避免后续业务代码出现意外异常。
4. 优先使用DI容器的原生能力：ASP.NET Core的DI容器支持工厂委托、Scoped服务的动态解析，尽量利用这些原生能力，而不是手动管理实例。

备注：内容来源于stack exchange，提问作者MyScooter