.NET Core 9.0 中 ASP.NET Core 中间件构造函数的重大变更解析-优快云博客

.NET Core 9.0 中 ASP.NET Core 中间件构造函数的重大变更解析

引言

在 .NET Core 9.0 中，ASP.NET Core 对中间件类型的构造函数处理方式进行了重要调整。这一变更主要影响那些定义了多个可满足构造函数的中间件类，可能导致运行时异常。本文将详细解析这一变更的背景、影响范围以及应对策略。

变更背景

在之前的版本中，当中间件类包含多个可满足的构造函数时，系统会默认选择参数最多的那个构造函数进行实例化。这种隐式选择机制虽然方便，但也带来了潜在的不确定性。

随着 .NET Core 9.0 引入了键控依赖注入（Keyed Dependency Injection）的支持，原有的构造函数选择机制需要做出相应调整，以提供更明确和可预测的行为。

变更详情

旧版行为（.NET 8 及之前）

考虑以下中间件类示例：

public class CookiePolicyMiddleware
{
    // 构造函数1：3个参数
    public CookiePolicyMiddleware(RequestDelegate next, 
        IOptions<CookiePolicyOptions> options, 
        ILoggerFactory factory)
    {
        // ...
    }

    // 构造函数2：2个参数
    public CookiePolicyMiddleware(RequestDelegate next, 
        IOptions<CookiePolicyOptions> options)
    {
        // ...
    }
}

在旧版本中，当两个构造函数都满足依赖注入条件时，系统会自动选择参数更多的构造函数1进行实例化。

新版行为（.NET 9 及之后）

在 .NET 9 中，行为发生了以下变化：

依赖注入容器支持 IServiceProviderIsService：如果容器实现了 IServiceProviderIsService 接口，仍会优先选择参数最多的构造函数
容器不支持 IServiceProviderIsService：则会抛出运行时异常，提示存在多个适用的构造函数

错误信息示例：

System.InvalidOperationException: 'Multiple constructors accepting all given argument types have been found in type 'Microsoft.AspNetCore.CookiePolicy.CookiePolicyMiddleware'. There should only be one applicable constructor.'

影响范围

此变更主要影响以下场景：

自定义中间件类中包含多个可满足的构造函数
使用不支持 IServiceProviderIsService 接口的依赖注入容器（如 Autofac 7.x）
特别是 CookiePolicyMiddleware 类在使用 Autofac.Extensions.DependencyInjection 7.x 时会出现问题

解决方案

方案1：升级依赖注入容器

优先考虑升级到支持 IServiceProviderIsService 接口的依赖注入容器版本。

方案2：显式标记首选构造函数

如果无法升级容器，可以在中间件类中使用 ActivatorUtilitiesConstructorAttribute 明确标记首选的构造函数：

public class CookiePolicyMiddleware
{
    [ActivatorUtilitiesConstructor]
    public CookiePolicyMiddleware(RequestDelegate next, 
        IOptions<CookiePolicyOptions> options, 
        ILoggerFactory factory)
    {
        // 标记为优先使用的构造函数
    }

    public CookiePolicyMiddleware(RequestDelegate next, 
        IOptions<CookiePolicyOptions> options)
    {
        // 备用构造函数
    }
}

方案3：简化构造函数设计

最佳实践是避免在中间件类中定义多个可满足的构造函数。通常一个中间件只需要一个明确的构造函数：

public class MyMiddleware
{
    // 唯一明确的构造函数
    public MyMiddleware(RequestDelegate next, 
        IOptions<MyOptions> options, 
        ILogger<MyMiddleware> logger)
    {
        // ...
    }
}

设计建议

单一职责原则：中间件类应该保持简单，通常只需要一个构造函数
显式优于隐式：避免依赖框架的隐式选择逻辑，明确指定构造方式
依赖明确化：将所有必需的依赖项都放在一个构造函数中，避免可选依赖导致的歧义

总结

.NET Core 9.0 对中间件构造函数的处理方式进行了更严格的规范，这虽然可能导致一些现有代码需要调整，但有助于提高应用程序的可靠性和可维护性。开发者应当：

检查项目中是否存在多个构造函数的中间件类
根据实际情况选择适当的升级或修改策略
遵循明确的构造函数设计原则，避免未来出现类似问题

这一变更体现了 .NET Core 对依赖注入规范化的持续改进，有助于构建更加健壮的应用程序架构。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考