ServiceProvider与ServiceDescriptor
服务的注册与提供
利用ServiceProvider来提供服务
提供一个服务实例的集合
获取ServiceProvider自身对象
对泛型的支持
我一直觉得优秀的设计首先应该是简单的设计，至少是看起来简单的设计，这就是我们所谓的大道至简。作为一个服务的提供者，ASP.NET Core中的DI容器最终体现为一个IServiceProvider接口，我们将所有实现了该接口的类型及其实例统称为ServiceProvider。如下面的代码片段所示，该接口简单至极，它仅仅提供了唯一个GetService方法，该方法根据提供的服务类型为你提供对应的服务实例。
interface IServiceProvider
2: {
object GetService(Type serviceType);
4: }
ASP.NET Core内部真正使用的是一个实现了IServiceProvider接口的内部类型（该类型的名称为“ServiceProvider”），我们不能直接创建该对象，只能间接地通过调用IServiceCollection接口的扩展方法BuildServiceProvider得到它。IServiceCollection接口定义在“Microsoft.Extensions.DependencyInjection”命名空间下，如果没有特别说明，本系列文章涉及到的与ASP.NET Core依赖注入相关的类型均采用此命名空间。 如下面的代码片段所示，IServiceCollection接口实际上代表一个元素为ServiceDescriptor对象的集合，它直接继承了另一个接口IList<ServiceDescriptor>，而ServiceCollection类实现了该接口。
class ServiceCollectionExtensions
2: {
this IServiceCollection services);
4: }
5:
interface IServiceCollection : IList<ServiceDescriptor>
7: {}
8:
class ServiceCollection: IServiceCollection
10: {
//省略成员
12: }
体现为DI容器的ServiceProvider之所以能够根据我们给定的服务类型（一般是一个接口类型）提供一个能够开箱即用的服务实例，是因为我们预先注册了相应的服务描述信息，这些指导ServiceProvider正确实施服务提供操作的服务描述体现为如下一个ServiceDescriptor类型。
class ServiceDescriptor
2: {
object instance);
object> factory, ServiceLifetime lifetime);
public ServiceDescriptor(Type serviceType, Type implementationType, ServiceLifetime lifetime);
6:
public Type ServiceType { get; }
public ServiceLifetime Lifetime { get; }
9:
public Type ImplementationType { get; }
object ImplementationInstance { get; }
object> ImplementationFactory { get; }
13: }
ServiceDescriptor的ServiceType属性代表提供服务的生命类型，由于标准化的服务一般会定义成接口，所以在绝大部分情况下体现为一个接口类型。类型为ServiceLifetime的属性Lifetime体现了ServiceProvider针对服务实例生命周期的控制方式。如下面的代码片段所示，ServiceLifetime是一个美剧类型，定义其中的三个选项（Singleton、Scoped和Transient）体现三种对服务对象生命周期的控制形式，我们将在本节后续部分对此作专门的介绍。
enum ServiceLifetime
2: {
3: Singleton,
4: Scoped,
5: Transient
6: }
对于ServiceDescriptor的其他三个属性来说，它们实际上是辅助ServiceProvider完成具体的服务实例提供操。ImplementationType属性代表被提供服务实例的真实类型，属性ImplementationInstance则直接代表被提供的服务实例，ImplementationFactory则提供了一个创建服务实例的委托对象。ASP.NET Core与依赖注入相关的几个核心类型具有如图10所示的关系。
由于ASP.NET Core中的ServiceProvider是根据一个代表ServiceDescriptor集合的IServiceCollection对象创建的，当我们调用其GetService方法的时候，它会根据我们提供的服务类型找到对应的ServiceDecriptor对象。如果该ServiceDecriptor对象的ImplementationInstance属性返回一个具体的对象，该对象将直接用作被提供的服务实例。如果ServiceDecriptor对象的ImplementationFactory返回一个具体的委托，该委托对象将直接用作创建服务实例的工厂。
如果这两个属性均为Null，ServiceProvider才会根据ImplementationType属性返回的类型调用相应的构造函数创建被提供的服务实例。至于我们在上面一节中提到的三种依赖注入方式，ServiceProvider仅仅支持构造器注入，属性注入和方法注入的支持并未提供。
二、服务的注册与提供
ASP.NET Core针对依赖注入的编程主要体现在两个方面：其一，创建一个ServiceCollection对象并将服务注册信息以ServiceDescriptor对象的形式添加其中；其二，针对ServiceCollection对象创建对应的ServiceProvider并利用它提供我们需要的服务实例。
在进行服务注册的时候，我们可以直接调用相应的构造函数创建ServiceDescriptor对象并将其添加到ServiceCollection对象之中。除此之外，IServiceCollection接口还具有如下三组扩展方法将这两个步骤合二为一。从下面给出的代码片段我们不难看出这三组扩展方法分别针对上面我们提及的三种针对服务实例的生命周期控制方式，泛型参数TService代表服务的声明类型，即ServiceDescriptor的ServiceType属性，至于ServiceDescriptor的其他属性，则通过方法相应的参数来提供。
class ServiceCollectionExtensions
2: {
class;
//其他AddScoped<TService>重载
5:
class;
//其他AddSingleton<TService>重载
8:
class;
//其他AddTransient<TService>重载
11: }
对于用作DI容器的ServiceProvider对象来说，我们可以直接调用它的GetService方法根据指定的服务类型获得想用的服务实例。除此之外，服务的提供还可以通过IServiceProvider接口相应的扩展方法来完成。如下面的代码片段所示，扩展方法GetService<T>以泛型参数的形式指定服务的声明类型。至于另外两个扩展方法GetRequiredService和GetRequiredService<T>，如果ServiceProvider不能提供一个具体的服务实例，一个InvalidOperationException异常会被抛出来并提示相应的服务注册信息不足。
class ServiceProviderExtensions
2: {
this IServiceProvider provider);
this IServiceProvider provider, Type serviceType);
this IServiceProvider provider);
6: }
利用ServiceProvider来提供服务
接下来采用实例演示的方式来介绍如何利用ServiceCollection进行服务注册，以及如何利用ServiceCollection创建对应的ServiceProvider来提供我们需要的服务实例。我们创建一个ASP.NET Core控制台程序，并在project.json中按照如下的方式添加针对 “Microsoft.Extensions.DepedencyInjection”这个NuGet包的依赖。
1: {
: {
4: },
5: ...
6: }
我们接下来定义四个服务接口（IFoo、IBar、IBaz和IGux）以及分别实现它们的四个服务类（Foo、Bar、Baz和Gux）如下面的代码片段所示，IGux具有三个只读属性（Foo、Bar和Baz）均为接口类型，并在构造函数中进行初始化。
interface IFoo {}
interface IBar {}
interface IBaz {}
interface IGux
5: {
6: IFoo Foo { get; }
7: IBar Bar { get; }
8: IBaz Baz { get; }
9: }
10:
class Foo : IFoo {}
class Bar : IBar {}
class Baz : IBaz {}
class Gux : IGux
15: {
private set; }
private set; }
private set; }
19:
public Gux(IFoo foo, IBar bar, IBaz baz)
21: {
this.Foo = foo;
this.Bar = bar;
this.Baz = baz;
25: }
26: }
现在我们在作为程序入口的Main方法中创建了一个ServiceCollection对象，并采用不同的方式完成了针对四个服务接口的注册。具体来说，对于正对服务接口IFoo和IGux的ServiceDescriptor来说，我们指定了代表服务真实类型的ImplementationType属性，而对于针对服务接口IBar和IBaz的ServiceDescriptor来说，我们初始化的则是分别代表服务实例和服务工厂的ImplementationInstance个ImplementationFactory属性。由于我们调用的是AddSingleton方法，所以四个ServiceDescriptor的Lifetime属性均为Singleton。
class Program
2: {
string[] args)
4: {
new ServiceCollection()
6: .AddSingleton<IFoo, Foo>()
new Bar())
new Baz())
9: .AddSingleton<IGux, Gux>();
10:
11: IServiceProvider serviceProvider = services.BuildServiceProvider();
,serviceProvider.GetService<IFoo>());
, serviceProvider.GetService<IBar>());
, serviceProvider.GetService<IBaz>());
, serviceProvider.GetService<IGux>());
16: }
17: }
接下来我们调用ServiceCollection对象的扩展方法BuildServiceProvider得到对应的ServiceProvider对象，然后调用其扩展方法GetService<T>分别获得针对四个接口的服务实例对象并将类型名称其输出到控制台上。运行该程序之后，我们会在控制台上得到如下的输出结果，由此印证ServiceProvider为我们提供了我们期望的服务实例。
1: serviceProvider.GetService<IFoo>(): Foo
2: serviceProvider.GetService<IBar>(): Bar
3: serviceProvider.GetService<IBaz>(): Baz
4: serviceProvider.GetService<IGux>(): Gux
提供一个服务实例的集合
如果我们在调用GetService方法的时候将服务类型指定为IEnumerable<T>，那么返回的结果将会是一个集合对象。除此之外， 我们可以直接调用IServiceProvider如下两个扩展方法GetServeces达到相同的目的。在这种情况下，ServiceProvider将会利用所有与指定服务类型相匹配的ServiceDescriptor来提供具体的服务实例，这些均会作为返回的集合对象的元素。如果所有的ServiceDescriptor均与指定的服务类型不匹配，那么最终返回的是一个空的集合对象。
class ServiceProviderExtensions
2: {
this IServiceProvider provider);
this IServiceProvider provider, Type serviceType);
5: }
值得一提的是，如果ServiceProvider所在的ServiceCollection包含多个具有相同服务类型（对应ServiceType属性）的ServiceDescriptor，当我们调用GetService方法获取单个服务实例的时候，只有最后一个ServiceDescriptor才是有效的，至于其他的ServiceDescriptor，它们只有在获取服务集合的场景下才有意义。
我们通过一个简单的实例来演示如何利用ServiceProvider得到一个包含多个服务实例的集合。我们在一个控制台应用中定义了如下一个服务接口IFoobar，两个服务类型Foo和Bar均实现了这个接口。在作为程序入口的Main方法中，我们将针针对服务类型Foo和Bar的两个ServiceDescriptor添加到创建的ServiceCollection对象中，这两个ServiceDescriptor对象的ServiceType属性均为IFoobar。
class Program
2: {
string[] args)
4: {
new ServiceCollection()
6: .AddSingleton<IFoobar, Foo>()
7: .AddSingleton<IFoobar, Bar>();
8:
9: IServiceProvider serviceProvider = serviceCollection.BuildServiceProvider();
, serviceProvider.GetService<IFoobar>());
11:
12: IEnumerable<IFoobar> services = serviceProvider.GetServices<IFoobar>();
int index = 1;
);
in services)
16: {
, index++, foobar);
18: }
19: }
20: }
21:
interface IFoobar {}
class Foo : IFoobar {}
class Bar : IFoobar {}
在调用ServiceCollection对象的扩展方法BuildServiceProvider得到对应的ServiceProvider对象之后，我们先调用其GetService<T>方法以确定针对服务接口IFoobar得到的服务实例的真实类型就是是Foo还是Bar。接下来我们调用ServiceProvider的扩展方法GetServices<T>获取一组针对服务接口IFoobar的服务实例并将它们的真是类型打印在控制台上。该程序运行后将会在控制台上生成如下的输出结果。
1: serviceProvider.GetService<IFoobar>(): Bar
2: serviceProvider.GetServices<IFoobar>():
3: 1: Foo
4: 2: Bar
获取ServiceProvider自身对象
对于ServiceProvider的服务提供机制来说，还有一个小小的细节值得我们关注，那就是当我们调用GetService或者GetRequiredService方法的时候若将服务类型设定为IServiceProvider，那么得到的对象实际上就是ServiceProvider自身这个对象。与之同理，调用GetServices方法将会返回一个包含自身的集合。如下所示的代码片段体现了ServiceProvider的这个特性。
class Program
2: {
string[] args)
4: {
new ServiceCollection().BuildServiceProvider();
object.ReferenceEquals(serviceProvider, serviceProvider.GetService<IServiceProvider>()));
object.ReferenceEquals(serviceProvider, serviceProvider.GetServices<IServiceProvider>().Single()));
8: }
9: }
对泛型的支持
ServiceProvider提供的服务实例不仅限于普通的类型，它对泛型服务类型同样支持。在针对泛型服务进行注册的时候，我们可以将服务类型设定为携带具体泛型参数的“关闭泛型类型”（比如IFoobar<IFoo,IBar>），除此之外服务类型也可以是包含具体泛型参数的“开放泛型类型”（比如IFoo<,>）。前者实际上还是将其视为非泛型服务来对待，后者才真正体现了“泛型”的本质。
比如我们注册了某个泛型服务接口IFoobar<,>与它的实现类Foobar<,>之间的映射关系，当我们指定一个携带具体泛型参数的服务接口类型IFoobar<IFoo,IBar>并调用ServiceProvider的GetService方法获取对应的服务实例时，ServiceProvider会针对指定的泛型参数类型(IFoo和IBar)来解析与之匹配的实现类型（可能是Foo和Baz）并得到最终的实现类型（Foobar<Foo,Baz>）。
我们同样利用一个简单的控制台应用来演示基于泛型的服务注册与提供方式。如下面的代码片段所示，我们定义了三个服务接口（IFoo、IBar和IFoobar<T1,T2>）和实现它们的三个服务类（Foo、Bar个Foobar<T1,T2>）,泛型接口具有两个泛型参数类型的属性（Foo和Bar），它们在实现类中以构造器注入的方式被初始化。
class Program
2: {
string[] args)
4: {
new ServiceCollection()
6: .AddTransient<IFoo, Foo>()
7: .AddTransient<IBar, Bar>()
typeof(Foobar<,>))
9: .BuildServiceProvider();
10:
, serviceProvider.GetService<IFoobar<IFoo, IBar>>().Foo);
, serviceProvider.GetService<IFoobar<IFoo, IBar>>().Bar);
13: }
14: }
15:
interface IFoobar<T1, T2>
17: {
18: T1 Foo { get; }
19: T2 Bar { get; }
20: }
interface IFoo {}
interface IBar {}
23:
class Foobar<T1, T2> : IFoobar<T1, T2>
25: {
private set; }
private set; }
public Foobar(T1 foo, T2 bar)
29: {
this.Foo = foo;
this.Bar = bar;
32: }
33: }
class Foo : IFoo {}
class Bar : IBar {}
在作为入口程序的Main方法中，我们创建了一个ServiceCollection对象并采用Transient模式注册了上述三个服务接口与对应实现类型之间的映射关系，对于泛型服务IFoobar<T1,T2>/Foobar<T1,T2>来说，我们指定的是不携带具体泛型参数的开放泛型类型IFoobar<,>/Foobar<,>。利用此ServiceCollection创建出对应的ServiceProvider之后，我们调用后者的GetService方法并指定IFoobar<IFoo,IBar>为服务类型。得到的服务对象将会是一个Foobar<Foo,Bar>对象，我们将它的Foo和Bar属性类型输出于控制台上作为验证。该程序执行之后将会在控制台上产生下所示的输出结果。
1: serviceProvider.GetService<IFoobar<IFoo, IBar>>().Foo: Foo
2: serviceProvider.GetService<IFoobar<IFoo, IBar>>().Bar: Bar
ASP.NET Core中的依赖注入（1）：控制反转（IoC）
ASP.NET Core中的依赖注入（2）：依赖注入（DI）
ASP.NET Core中的依赖注入（3）：服务注册与提取
ASP.NET Core中的依赖注入（4）：构造函数的选择与生命周期管理
ASP.NET Core中的依赖注入（5）：ServicePrvider实现揭秘【总体设计】
ASP.NET Core中的依赖注入（5）：ServicePrvider实现揭秘【解读ServiceCallSite】
ASP.NET Core中的依赖注入（5）：ServicePrvider实现揭秘【补充漏掉的细节】
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
请发表评论