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
