ASP.NET Core 7.0 SignalR Hub方法参数解析机制的重大变更-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00060/article/details/148549061

ASP.NET Core 7.0 SignalR Hub方法参数解析机制的重大变更

docs This repository contains .NET Documentation. 项目地址: https://gitcode.com/gh_mirrors/docs2/docs

引言

在ASP.NET Core 7.0中，SignalR Hub方法的参数解析机制发生了重要变化。这一改进使得Hub方法能够直接从依赖注入(DI)容器中解析参数，为开发者提供了更大的灵活性。本文将详细介绍这一变更的内容、原因以及应对策略。

变更概述

在ASP.NET Core 7.0之前，SignalR Hub方法的所有参数都只能从客户端消息中获取。而在7.0版本中，框架会在应用启动时检查DI容器，自动判断哪些参数应该从DI解析，哪些应该从客户端消息获取。

变更细节

旧版行为

在7.0之前的版本中，即使某个类型已在DI容器中注册，Hub方法参数仍然只会从客户端消息中获取：

// 服务注册
Services.AddScoped<SomeCustomType>();

class MyHub : Hub
{
    // type参数总是来自客户端，不会从DI解析
    public Task Method(string text, SomeCustomType type) => Task.CompletedTask;
}

新版行为

在7.0版本中，框架会使用IServiceProviderIsService在应用启动时检查DI容器。如果发现Hub方法的参数类型已在DI中注册，则会优先从DI解析该参数：

// 服务注册
Services.AddScoped<SomeCustomType>();

class MyHub : Hub
{
    // SomeCustomType现在默认从DI解析
    public Task Method(string text, SomeCustomType type) => Task.CompletedTask;
}

如果客户端尝试发送SomeCustomType参数，将会收到错误。

变更影响

这一变更属于源代码兼容性变更，可能会影响以下场景：

应用中同时满足：
- 某个类型已在DI容器中注册
- 该类型又作为Hub方法的参数
- 客户端确实会发送该类型的参数

不过这种场景在实际开发中并不常见，因此大多数应用不会受到影响。

变更原因

这一改进主要基于以下考虑：

提升开发体验：开发者现在可以更灵活地在不同Hub方法中使用不同的服务
性能优化：不再需要将所有依赖都注入到Hub的构造函数中
一致性：与ASP.NET Core其他部分的参数解析机制保持一致

应对策略

方案一：完全禁用新特性

如果这一变更导致你的应用出现问题，可以通过以下配置完全禁用新特性：

Services.AddSignalR(options =>
{
    options.DisableImplicitFromServicesParameters = true;
});

方案二：选择性使用新特性

如果你想保留新特性，同时避免对现有客户端造成影响，可以采用以下方式：

Services.AddScoped<SomeCustomType>();
Services.AddScoped<SomeCustomType2>();

class MyHub : Hub
{
    // 旧方法兼容性处理：只有SomeCustomType2从DI解析
    public Task MethodA(string arguments, SomeCustomType type, [FromServices] SomeCustomType2 type2);

    // 新方法：明确指定SomeCustomType从DI解析
    public Task MethodB(string arguments, [FromServices] SomeCustomType type);
}