.NET全局静态可访问IServiceProvider的过程详解(支持Blazor)
作者：nigture
DependencyInjection.StaticAccessor
前言
如何在静态方法中访问DI容器长期以来一直都是一个令人苦恼的问题，特别是对于热爱编写扩展方法的朋友。之所以会为这个问题苦恼，是因为一个特殊的服务生存期——范围内（Scoped），所谓的Scoped就是范围内单例，最常见的WebAPI/MVC中一个请求对应一个范围，所有注册为Scoped的对象在同一个请求中是单例的。如果仅仅用一个静态字段存储应用启动时创建出的IServiceProvider对象，那么在一个请求中通过该字段是无法正确获取当前请求中创建的Scoped对象的。
在早些时候有针对肉夹馍（Rougamo）访问DI容器发布了一些列NuGet，由于肉夹馍不仅能应用到实例方法上还能够应用到静态方法上，所以肉夹馍访问DI容器的根本问题就是如何在静态方法中访问DI容器。考虑到静态方法访问DI容器是一个常见的公共问题，所以现在将核心逻辑抽离成一系列单独的NuGet包，方便不使用肉夹馍的朋友使用。
快速开始
启动项目引用DependencyInjection.StaticAccessor.Hosting
dotnet add package DependencyInjection.StaticAccessor.Hosting
非启动项目引用DependencyInjection.StaticAccessor
dotnet add package DependencyInjection.StaticAccessor
// 1. 初始化。这里用通用主机进行演示，其他类型项目后面将分别举例
var builder = Host.CreateDefaultBuilder();
builder.UsePinnedScopeServiceProvider(); // 仅此一步完成初始化
var host = builder.Build();
host.Run();
// 2. 在任何地方获取
class Test
{
public static void M()
{
var yourService = PinnedScope.ScopedServices.GetService<IYourService>();
}
}如上示例，通过静态属性PinnedScope.ScopedServices即可获取当前Scope的IServiceProvider对象，如果当前不在任何一个Scope中时，该属性返回根IServiceProvider。
版本说明
由于DependencyInjection.StaticAccessor的实现包含了通过反射访问微软官方包非public成员，官方的内部实现随着版本的迭代也在不断地变化，所以针对官方包不同版本发布了对应的版本。DependencyInjection.StaticAccessor的所有NuGet包都采用语义版本号格式（SemVer），其中主版本号与Microsoft.Extensions.*相同，次版本号为功能发布版本号，修订号为BUG修复及微小改动版本号。请各位在安装NuGet包时选择与自己引用的Microsoft.Extensions.*主版本号相同的最新版本。
另外需要说明的是，由于我本地创建blazor项目时只能选择.NET8.0，所以blazor相关包仅提供了8.0版本，如果确实有低版本的需求，可以到github中提交issue。
WebAPI/MVC初始化示例
启动项目引用DependencyInjection.StaticAccessor.Hosting
dotnet add package DependencyInjection.StaticAccessor.Hosting
非启动项目引用DependencyInjection.StaticAccessor
dotnet add package DependencyInjection.StaticAccessor
var builder = WebApplication.CreateBuilder(); builder.Host.UsePinnedScopeServiceProvider(); // 唯一初始化步骤 var app = builder.Build(); app.Run();
Blazor使用示例
Blazor的DI Scope是一个特殊的存在，在WebAssembly模式下Scoped等同于单例；而在Server模式下，Scoped对应一个SignalR连接。针对Blazor的这种特殊的Scope场景，除了初始化操作，还需要一些额外操作。
我们知道，Blazor项目在创建时可以选择交互渲染模式，除了Server模式外，其他的模式都会创建两个项目，多出来的这个项目的名称以.Client结尾。这里我称.Client项目为Client端项目，另一个项目为Server端项目（Server模式下唯一的那个项目也称为Server端项目）。
Server端项目
安装NuGet
启动项目引用
DependencyInjection.StaticAccessor.Blazordotnet add package DependencyInjection.StaticAccessor.Blazor
非启动项目引用
DependencyInjection.StaticAccessordotnet add package DependencyInjection.StaticAccessor
初始化
var builder = WebApplication.CreateBuilder(); builder.Host.UsePinnedScopeServiceProvider(); // 唯一初始化步骤 var app = builder.Build(); app.Run();
页面继承PinnedScopeComponentBase
推荐直接在_Imports.razor中声明。
// _Imports.razor @inherits DependencyInjection.StaticAccessor.Blazor.PinnedScopeComponentBase
Client端项目
与Server端步骤基本一致，只是引用的NuGet有所区别：
安装NuGet
启动项目引用
DependencyInjection.StaticAccessor.Blazor.WebAssemblydotnet add package DependencyInjection.StaticAccessor.Blazor.WebAssembly
非启动项目引用
DependencyInjection.StaticAccessordotnet add package DependencyInjection.StaticAccessor
初始化
var builder = WebAssemblyHostBuilder.CreateDefault(args); builder.UsePinnedScopeServiceProvider(); await builder.Build().RunAsync();
页面继承PinnedScopeComponentBase
推荐直接在_Imports.razor中声明。
// _Imports.razor @inherits DependencyInjection.StaticAccessor.Blazor.PinnedScopeComponentBase
已有自定义ComponentBase基类的解决方案
你可能会使用其他包定义的ComponentBase基类，由于C#不支持多继承，所以这里提供了不继承PinnedScopeComponentBase的解决方案。
// 假设你现在使用的ComponentBase基类是ThirdPartyComponentBase
// 定义新的基类继承ThirdPartyComponentBase
public class YourComponentBase : ThirdPartyComponentBase, IHandleEvent, IServiceProviderHolder
{
private IServiceProvider _serviceProvider;
[Inject]
public IServiceProvider ServiceProvider
{
get => _serviceProvider;
set
{
PinnedScope.Scope = new FoolScope(value);
_serviceProvider = value;
}
}
Task IHandleEvent.HandleEventAsync(EventCallbackWorkItem callback, object? arg)
{
return this.PinnedScopeHandleEventAsync(callback, arg);
}
}
// _Imports.razor
@inherits YourComponentBase其他ComponentBase基类
除了PinnedScopeComponentBase，还提供了PinnedScopeOwningComponentBase和PinnedScopeLayoutComponentBase，后续会根据需要可能会加入更多类型。如有需求，也欢迎反馈和提交PR.
注意事项
避免通过PinnedScope直接操作IServiceScope
虽然你可以通过PinnedScope.Scope获取当前的DI Scope，但最好不要通过该属性直接操作IServiceScope对象，比如调用Dispose方法，你应该通过你创建Scope时创建的变量进行操作。
不支持非通常Scope
一般日常开发时不需要关注这个问题的，通常的AspNetCore项目也不会出现这样的场景，而Blazor就是官方项目类型中一个非通常DI Scope的案例。
在解释什么是非通常Scope前，我先聊聊通常的Scope模式。我们知道DI Scope是可以嵌套的，在通常情况下，嵌套的Scope呈现的是一种栈的结构，后创建的scope先释放，井然有序。
using (var scope11 = serviceProvider.CreateScope()) // push scope11. [scope11]
{
using (var scope21 = scope11.ServiceProvider.CreateScope()) // push scope21. [scope11, scope21]
{
using (var scope31 = scope21.ServiceProvider.CreateScope()) // push scope31. [scope11, scope21, scope31]
{
} // pop scope31. [scope11, scope21]
using (var scope32 = scope21.ServiceProvider.CreateScope()) // push scope32. [scope11, scope21, scope32]
{
} // pop scope32. [scope11, scope21]
} // pop scope21. [scope11]
using (var scope22 = scope11.ServiceProvider.CreateScope()) // push scope22. [scope11, scope22]
{
} // pop scope22. [scope22]
} // pop scope11. []了解了非通常Scope，那么就很好理解非通常Scope了，只要是不按照这种井然有序的栈结构的，那就是非通常Scope。比较常见的就是Blazor的这种情况：
我们知道，Blazor SSR通过SignalR实现SPA，一个SignalR连接对应一个DI Scope，界面上的各种事件（点击、获取焦点等）通过SignalR通知服务端回调事件函数，而这个回调便是从外部横插一脚与SignalR进行交互的，在不进行特殊处理的情况下，回调事件所属的Scope是当前回调事件新创建的Scope，但我们在回调事件中与之交互的Component是SignalR所属Scope创建的，这就出现了Scope交叉交互的情况。PinnedScopeComponentBase所做的便是在执行回调函数之前，将PinnedScope.Scope重设回SignalR对应Scope。
肉夹馍相关应用
正如前面所说，DependencyInjection.StaticAccessor的核心逻辑是从肉夹馍的DI扩展中抽离出来的，抽离后肉夹馍DI扩展将依赖于DependencyInjection.StaticAccessor。现在你可以直接引用DependencyInjection.StaticAccessor，然后直接通过PinnedScope.Scope与DI进行交互，但还是推荐通过肉夹馍DI扩展进行交互，DI扩展提供了一些额外的功能，稍后将一一介绍。
DI扩展包变化
Autofac相关包未发生重大变化，后续介绍的扩展包都是官方DependencyInjection的相关扩展包
本次不仅仅是一个简单的代码抽离，代码的核心实现上也有更新，更新后移出了扩展方法CreateResolvableScope，直接支持官方的CreateScope和CreateAsyncScope方法。同时扩展包Rougamo.Extensions.DependencyInjection.AspNetCore和Rougamo.Extensions.DependencyInjection.GenericHost合并为Rougamo.Extensions.DependencyInjection.Microsoft。
Rougamo.Extensions.DependencyInjection.Microsoft
仅定义切面类型的项目需要引用Rougamo.Extensions.DependencyInjection.Microsoft，启动项目根据项目类型引用DependencyInjection.StaticAccessor相关包即可，初始化也是仅需要完成DependencyInjection.StaticAccessor初始化即可。
更易用的扩展
Rougamo.Extensions.DependencyInjection.Microsoft针对MethodContext提供了丰富的DI扩展方法，简化代码编写。
public class TestAttribute : AsyncMoAttribute
{
public override ValueTask OnEntryAsync(MethodContext context)
{
context.GetService<ITestService>();
context.GetRequiredService(typeof(ITestService));
context.GetServices<ITestService>();
}
}从当前宿主类型实例中获取IServiceProvider
DependencyInjection.StaticAccessor提供的是一种常用场景下获取当前Scope的IServiceProvider解决方案，但在千奇百怪的开发需求中，总会出现一些不寻常的DI Scope场景，比如前面介绍的非通常Scope，再比如Blazor。针对这种场景，肉夹馍DI扩展虽然不能帮你获取到正确的IServiceProvider对象，但如果你自己能够提供获取方式，肉夹馍DI扩展可以方便的集成该获取方式。
下面以Blazor为例，虽然已经针对Blazor特殊的DI Scope提供了通用解决方案，但Blazor还存在着自己的特殊场景。我们知道Blazor SSR服务生存期是整个SignalR的生存期，这个生存期可能非常长，一个生存期期间可能会创建多个页面（ComponentBase），这多个页面也将共享注册为Scoped的对象，这在某些场景下可能会存在问题（比如共享EF DBContext），所以微软提供了OwningComponentBase，它提供了更短的服务生存期，集成该类可以通过ScopedServices属性访问IServiceProvider对象。
// 1. 定义前锋类型，针对OwningComponentBase返回ScopedServices属性
public class OwningComponentScopeForward : SpecificPropertyFoolScopeProvider, IMethodBaseScopeForward
{
public override string PropertyName => "ScopedServices";
}
// 2. 初始化
var builder = WebApplication.CreateBuilder();
// 初始化DependencyInjection.StaticAccessor
builder.Host.UsePinnedScopeServiceProvider();
// 注册前锋类型
builder.Services.AddMethodBaseScopeForward<OwningComponentScopeForward>();
var app = builder.Build();
app.Run();
// 3. 使用
public class TestAttribute : AsyncMoAttribute
{
public override ValueTask OnEntryAsync(MethodContext context)
{
// 当TestAttribute应用到OwningComponentBase子类方法上时，ITestService将从OwningComponentBase.ScopedServices中获取
context.GetService<ITestService>();
}
}除了上面示例中提供的OwningComponentScopeForward，还有根据字段名称获取的SpecificFieldFoolScopeProvider，根据宿主类型通过lambda表达式获取的TypedFoolScopeProvider<>，这里就不一一举例了，如果你的获取逻辑更加复杂，可以直接实现先锋类型接口IMethodBaseScopeForward。
除了前锋类型接口IMethodBaseScopeForward，还提供了守门员类型接口IMethodBaseScopeGoalie，在调用GetService系列扩展方法时，内部实现按 [先锋类型 -> PinnedScope.Scope.ServiceProvider -> 守门员类型 -> PinnedScope.RootServices] 的顺序尝试获取IServiceProvider对象。
完整示例
完整示例请访问：https://github.com/inversionhourglass/Rougamo.DI/tree/master/samples
到此这篇关于.NET全局静态可访问IServiceProvider（支持Blazor）的文章就介绍到这了,更多相关.NET全局静态可访问IServiceProvider内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！