本文共 5919 字,大约阅读时间需要 19 分钟。
在上一篇文章中,我们学习了Microsoft.Extensions.DependencyInjection
中的IServiceCollection,包括服务注册转换为ServiceDescriptors,然后添加到集合中。
探索 .NET Core 依赖注入的 IServiceCollection[1]
在本文中,我们会学习 IServiceProvider,了解它是什么,以及它是怎么创建出来的,我们将根据上一篇文章中创建的IServiceCollection来学习如何构建IServiceProvider。
IServiceProvider会根据程序的要求在运行时解析服务类型的实例,ServiceProvider来保证已解析的服务在预期的生命周期内有效,这个实现设计的非常高效,所以服务的解析速度非常快。
首先,当我们把服务都添加到 IServiceCollection ,接下来会构建一个IServiceProvider, 它能够提供我们程序中所依赖服务的实例,本质上它包装了 IServiceCollection。
通过调用 BuildServiceProvider(IServiceCollection上的一个扩展方法)完成构建:
var serviceCollection = new ServiceCollection();serviceCollection.AddSingleton();serviceCollection.AddSingleton ();var serviceProvider = serviceCollection.BuildServiceProvider();
当我们没有传入任何参数时,它会创建一个 ServiceProviderOptions 的一个默认实例:
public static class ServiceCollectionContainerBuilderExtensions{ public static ServiceProvider BuildServiceProvider(this IServiceCollection services) { return services.BuildServiceProvider(ServiceProviderOptions.Default); }
ServiceProviderOptions 有两个属性,在本文后边的内容,我会详细介绍这些:
public class ServiceProviderOptions{ public bool ValidateScopes { get; set; } public bool ValidateOnBuild { get; set; }}
BuildServiceProvider 的方法内部是这样的:
public static ServiceProvider BuildServiceProvider(this IServiceCollection services, ServiceProviderOptions options){ if (services == null) { throw new ArgumentNullException(nameof(services)); } if (options == null) { throw new ArgumentNullException(nameof(options)); } IServiceProviderEngine engine;#if !NETCOREAPP engine = new DynamicServiceProviderEngine(services);#else if (RuntimeFeature.IsDynamicCodeCompiled) { engine = new DynamicServiceProviderEngine(services); } else { // Don't try to compile Expressions/IL if they are going to get interpreted engine = new RuntimeServiceProviderEngine(services); }#endif return new ServiceProvider(services, engine, options);}
最终,它会创建并返回一个 ServiceProvider。
在上面的代码中,ServiceProvider选择应该使用哪个 engine, engine 是一个组件,它的功能是负责 DI容器中服务实例的创建,然后把实例注入到其他服务中。
这些是 IServiceProviderEngine 的四个实现:
•Dynamic•Runtime•ILEmit•Expressions (System.Linq.Expressions)
从上面的代码中,我们可以看到在大多数情况下会使用 DynamicServiceProviderEngine,仅在目标框架不支持动态代码编译的情况下,才使用RuntimeServiceProviderEngine,DynamicServiceProviderEngine 会使用 ILEmit 或者 Expressions 来解析服务。
我们看一下 ServiceProviderEngine 的构造函数的内容:
protected ServiceProviderEngine(IEnumerableserviceDescriptors){ _createServiceAccessor = CreateServiceAccessor; Root = new ServiceProviderEngineScope(this); RuntimeResolver = new CallSiteRuntimeResolver(); CallSiteFactory = new CallSiteFactory(serviceDescriptors); CallSiteFactory.Add(typeof(IServiceProvider), new ServiceProviderCallSite()); CallSiteFactory.Add(typeof(IServiceScopeFactory), new ServiceScopeFactoryCallSite()); RealizedServices = new ConcurrentDictionary >();}
它创建一个 Root ServiceProviderEngineScope,然后传入this, scopes限制了服务的生命周期,最常见的就是,.Net Core 收到一个接口请求时,它创建的服务就是 Scope 类型。
这种情况下,我们注册的单例服务,它都是从 Root Scope 返回的。
然后创建一个 CallSiteRuntimeResolver,我会在接下来的文章介绍它。
最后,在上面的构造函数中,将创建一个新的ConcurrentDictionary来保存有关服务的信息,按需设计,只有开始使用这些服务时,它才会开始创建,如果有些服务注册了,但是没有使用的话,那么它永远不会创建。
让我们回到 BuildServiceProvider 方法的最后一行,它会传入 IServiceCollection, Engine和ServiceProviderOptions:
internal ServiceProvider(IEnumerableserviceDescriptors, IServiceProviderEngine engine, ServiceProviderOptions options){ _engine = engine; if (options.ValidateScopes) { _engine.InitializeCallback(this); _callSiteValidator = new CallSiteValidator(); } if (options.ValidateOnBuild) { List exceptions = null; foreach (ServiceDescriptor serviceDescriptor in serviceDescriptors) { try { _engine.ValidateService(serviceDescriptor); } catch (Exception e) { exceptions = exceptions ?? new List (); exceptions.Add(e); } } if (exceptions != null) { throw new AggregateException("Some services are not able to be constructed", exceptions.ToArray()); } }}
在上面的代码中,我们可以看到在构造函数中使用了ServiceProviderOptions, 当ValidateScopes为true时,ServiceProvider会传入this调用 engine 的 InitializeCallback方法,它还创建一个新的CallSiteValidator。
如果 ValidateOnBuild 为true的话,它会检查DI容器中已注册的所有服务,遍历了ServiceDescriptor 集合,然后调用 ValidateService, 检查服务,并且这里捕获了异常,如果有错误,会抛出一个聚合的异常信息。
那么在程序中使用 ValidateOnBuild,可以保证在程序启动时就检查已注册的错误服务,而不是在首次解析服务时在运行时捕获异常,这个可以很好的帮助排除问题。
ValidateService 的方法内部如下:
public void ValidateService(ServiceDescriptor descriptor){ if (descriptor.ServiceType.IsGenericType && !descriptor.ServiceType.IsConstructedGenericType) { return; } try { ServiceCallSite callSite = CallSiteFactory.GetCallSite(descriptor, new CallSiteChain()); if (callSite != null) { _callback?.OnCreate(callSite); } } catch (Exception e) { throw new InvalidOperationException($"Error while validating the service descriptor '{descriptor}': {e.Message}", e); }}
在本文中,我们重点介绍了如何从IServiceCollection来构建IServiceProvider,我们探索了一些实现细节,以了解如何应用ValidateScopes和ValidateOnBuild ServiceProviderOptions,我们在这篇文章中谈到了很多内部代码,但作为库的使用者,您不必担心这些细节。
最重要的一点是,在IServiceCollection上调用BuildServiceProvider之后,将创建默认的ServiceProvider。
var serviceProvider = serviceCollection.BuildServiceProvider();
也可以传入 ServiceProviderOptions
var serviceProviderWithOptions = serviceCollection.BuildServiceProvider(new ServiceProviderOptions{ ValidateOnBuild = true, ValidateScopes = true});
原文链接: https://www.stevejgordon.co.uk/aspnet-core-dependency-injection-what-is-the-iserviceprovider-and-how-is-it-built[2]
欢迎扫码关注我们的公众号 【全球技术精选】,专注国外优秀博客的翻译和开源项目分享,也可以添加QQ群 897216102
转载地址:http://uoudi.baihongyu.com/