ServiceProvider最终提供的服务实例都是根据对应的ServiceDescriptor创建的，对于一个具体的ServiceDescriptor对象来说，如果它的ImplementationInstance和ImplementationFactory属性均为Null，那么ServiceProvider最终会利用其ImplementationType属性返回的真实类型选择一个适合的构造函数来创建最终的服务实例。我们知道服务服务的真实类型可以定义了多个构造函数，那么ServiceProvider针对构造函数的选择会采用怎样的策略呢？
目录
一、构造函数的选择
二、生命周期管理
ServiceScope与ServiceScopeFactory
三种生命周期管理模式
服务实例的回收
一、构造函数的选择
如果ServiceProvider试图通过调用构造函数的方式来创建服务实例，传入构造函数的所有参数必须先被初始化，最终被选择出来的构造函数必须具备一个基本的条件：ServiceProvider能够提供构造函数的所有参数。为了让读者朋友能够更加真切地理解ServiceProvider在构造函数选择过程中采用的策略，我们不让也采用实例演示的方式来进行讲解。
我们在一个控制台应用中定义了四个服务接口（IFoo、IBar、IBaz和IGux）以及实现它们的四个服务类（Foo、Bar、Baz和Gux）。如下面的代码片段所示，我们为Gux定义了三个构造函数，参数均为我们定义了服务接口类型。为了确定ServiceProvider最终选择哪个构造函数来创建目标服务实例，我们在构造函数执行时在控制台上输出相应的指示性文字。
1: public interface IFoo {}
2: interface IBar {}
3: interface IBaz {}
4: interface IGux {}
5:
6: class Foo : IFoo {}
7: class Bar : IBar {}
8: class Baz : IBaz {}
9: class Gux : IGux
10: {
11: public Gux(IFoo foo)
12: {
13: Console.WriteLine("Gux(IFoo)");
14: }
15:
16: public Gux(IFoo foo,IBar bar)
17: {
18: Console.WriteLine("Gux(IFoo,IBar)");
19: }
20:
21: 22: {
23: Console.WriteLine();
24: }
25: }
我们在作为程序入口的Main方法中创建一个ServiceCollection对象并在其中添加针对IFoo、IBar以及IGux这三个服务接口的服务注册，针对服务接口IBaz的注册并未被添加。我们利用由它创建的ServiceProvider来提供针对服务接口IGux的实例，究竟能否得到一个Gux对象呢？如果可以，它又是通过执行哪个构造函数创建的呢？
4: {
6: .AddTransient<IFoo,Foo>()
8: .AddTransient<IGux,Gux>()
10: .GetServices<IGux>();
12: }
对于定义在Gux中的三个构造函数来说，ServiceProvider所在的ServiceCollection包含针对接口IFoo和IBar的服务注册，所以它能够提供前面两个构造函数的所有参数。由于第三个构造函数具有一个类型为IBaz的参数，这无法通过ServiceProvider来提供。根据我们上面介绍的第一个原则（ServiceProvider能够提供构造函数的所有参数），Gux的前两个构造函数会成为合法的候选构造函数，那么ServiceProvider最终会选择哪一个呢？
在所有合法的候选构造函数列表中，最终被选择出来的构造函数具有这么一个特征：每一个候选构造函数的参数类型集合都是这个构造函数参数类型集合的子集。如果这样的构造函数并不存在，一个类型为InvalidOperationException的异常会被跑出来。根据这个原则，Gux的第二个构造函数的参数类型包括IFoo和IBar，而第一个构造函数仅仅具有一个类型为IFoo的参数，最终被选择出来的会是Gux的第二个构造函数，所有运行我们的实例程序将会在控制台上产生如下的输出结果。
8: .AddTransient<IBaz,Baz>()
11: .GetServices<IGux>();
13: }
15: 16: {
18: public Gux(IBar bar,IBaz baz) {}
1: Unhandled Exception: System.InvalidOperationException: Unable to activate type 'Gux'. The following constructors are ambigious:
3: Void .ctor(IBar,IBaz)
interface IServiceScope : IDisposable
4: }
7: {
9: }
若要充分理解ServiceScope和ServiceProvider之间的关系，我们需要简单了解一下ServiceProvider的层级结构。除了直接通过一个ServiceCollection对象创建一个独立的ServiceProvider对象之外，一个ServiceProvider还可以根据另一个ServiceProvider对象来创建，如果采用后一种创建方式，我们指定的ServiceProvider与创建的ServiceProvider将成为一种“父子”关系。
5: {
7: }
9: }
由于ServiceProvider自身是一个内部类型，我们不能采用调用构造函数的方式根据一个作为“父亲”的ServiceProvider创建另一个作为“儿子”的ServiceProvider，但是这个目的可以间接地通过创建ServiceScope的方式来完成。如下面的代码片段所示，我们首先创建一个独立的ServiceProvider并调用其GetService<T>方法获得一个ServiceScopeFactory对象，然后调用后者的CreateScope方法创建一个新的ServiceScope，它的ServiceProvider就是前者的“儿子”。
7:
9: Debug.Assert(object.ReferenceEquals(serviceProvider1,root));
11: }
如果读者朋友们希望进一步了解ServiceScope的创建以及它和ServiceProvider之间的关系，我们不妨先来看看作为IServiceScope接口默认实现的内部类型ServiceScope的定义。如下面的代码片段所示，ServiceScope仅仅是对一个ServiceProvider对象的简单封装而已。值得一提的是，当ServiceScope的Dispose方法被调用的时候，这个被封装的ServiceProvider的同名方法同时被执行。
this._scopedProvider = scopedProvider;
void Dispose()
10: _scopedProvider.Dispose();
13: public IServiceProvider ServiceProvider
15: get {return _scopedProvider; }
17: }
IServiceScopeFactory接口的默认实现类型是一个名为ServiceScopeFactory的内部类型。如下面的代码片段所示，ServiceScopeFactory的只读字段“_provider”表示当前的ServiceProvider。当CreateScope方法被调用的时候，这个ServiceProvider的“子ServiceProvider”被创建出来，并被封装成返回的ServiceScope对象。
6: _provider = provider;
9: public IServiceScope CreateScope()
11: return new ServiceScope(new ServiceProvider(_provider));
4:
5: IServiceProvider root = 7: .AddScoped<IBar,1)"> 8: .AddSingleton<IBaz,1)"> 9: .BuildServiceProvider();
11: IServiceProvider child2 = root.GetService<IServiceScopeFactory>().CreateScope().ServiceProvider;
14: Console.WriteLine("ReferenceEquals(child1.GetService<IBar>(),child1.GetService<IBar>() = {0}",ReferenceEquals(child1.GetService<IBar>(),child1.GetService<IBar>()));
16: Console.WriteLine("ReferenceEquals(child1.GetService<IBaz>(),child2.GetService<IBaz>() = {0}",ReferenceEquals(child1.GetService<IBaz>(),child2.GetService<IBaz>()));
18: }
为了验证ServiceProvider针对Transient模式是否总是创建新的服务实例，我们利用同一个ServiceProvider（root）获取针对服务接口IFoo的实例并进行比较。为了验证ServiceProvider针对Scope模式是否仅仅在当前ServiceScope下具有“单例”的特性，我们先后比较了同一个ServiceProvider（child1）和不同ServiceProvider（child1和child2）两次针对服务接口IBar获取的实例。为了验证具有“同根”的所有ServiceProvider针对Singleton模式总是返回同一个服务实例，我们比较了两个不同child1和child2两次针对服务接口IBaz获取的服务实例。如下所示的输出结构印证了我们上面的论述。
4: ReferenceEquals(child1.GetService<IBaz>(),child2.GetService<IBaz>() = True
服务实例的回收
ServiceProvider除了为我们提供所需的服务实例之外，对于由它提供的服务实例，它还肩负起回收之责。这里所说的回收与.NET自身的垃圾回收机制无关，仅仅针对于自身类型实现了IDisposable接口的服务实例，所谓的回收仅仅体现为调用它们的Dispose方法。ServiceProvider针对服务实例所采用的收受策略取决于服务注册时采用的生命周期管理模式，具体采用的服务回收策略主要体现为如下两点：
- 如果注册的服务采用Singleton模式，由某个ServiceProvider提供的服务实例的回收工作由作为根的ServiceProvider负责，后者的Dispose方法被调用的时候，这些服务实例的Dispose方法会自动执行。
- 如果注册的服务采用其他模式（Scope或者Transient），ServiceProvider自行承担由它提供的服务实例的回收工作，当它的Dispose方法被调用的时候，这些服务实例的Dispose方法会自动执行。
我们照例使用一个简单的实例来演示ServiceProvider针对不同生命周期管理模式所采用的服务回收策略。我们在一个控制台应用中定义了如下三个服务接口（IFoo、IBar和IBaz）以及三个实现它们的服务类（Foo、Bar和Baz），这些类型具有相同的基类Disposable。Disposable实现了IDisposable接口，我们在Dispose方法中输出相应的文字以确定对象回收的时机。
class Disposable : IDisposable
15: }
我们在作为程序入口的Main方法中创建了一个ServiceCollection对象，并在其中采用不同的生命周期管理模式注册了三个相应的服务（IFoo/Foo、IBar/Bar和IBaz/Baz分别采用Transient、Scoped和Singleton模式）。我们针对这个ServiceCollection创建了一个ServiceProvider（root），以及它的两个“儿子”（child1和child2）。在分别通过child1和child2提供了两个服务实例（child1：IFoo， child2：IBar/IBaz）之后，我们先后调用三个ServiceProvider（child1=>child2=>root）的Dispose方法。
16: child2.GetService<IBaz>();
"child1.Dispose()");
21: Console.WriteLine("child2.Dispose()");
23:
25: ((IDisposable)root).Dispose();
26: }
27: }
该程序运行之后会在控制台上产生如下的输出结果。从这个结果我们不难看出由child1提供的两个采用Transient模式的服务实例的回收实在child1的Dispose方法执行之后自动完成的。当child2的Dispose方法被调用的时候，对于由它提供的两个服务对象来说，只有注册时采用Scope模式的Bar对象被自动回收了，至于采用Singleton模式的Baz对象的回收工作，是在root的Dispose方法被调用之后自动完成的。
4: child2.Dispose()
6: root.Dispose()
void DoWork(IServiceProvider serviceProvider)
5: ...
3: IFoobar foobar = serviceProvider.GetService<IFoobar>();
6: ...
10: (foobar as IDisposable)?.Dispose();
using (IServiceScope serviceScope = serviceProvider.GetService<IServiceScopeFactory>().CreateScope())
8: }
接下来我们通过一个简单的实例演示上述这两种针对服务回收的编程方式之间的差异。我们在一个控制台应用中定义了一个继承自IDisposable的服务接口IFoobar和实现它的服务类Foobar。如下面的代码片段所示，为了确认对象真正被GC回收的时机，我们为Foobar定义了一个析构函数。在该析构函数和Dispose方法中，我们还会在控制台上输出相应的指导性文字。
class Foobar : IFoobar
6: ~Foobar()
8: Console.WriteLine("Foobar.Finalize()");
10:
15: }
在作为程序入口的Main方法中，我们创建了一个ServiceCollection对象并采用Transient模式将IFoobbar/Foobar注册其中。借助于通过该ServiceCollection创建的ServiceProvider，我们分别采用上述的两种方式获取服务实例并试图对它实施回收。为了强制GC试试垃圾回收，我们显式调用了GC的Collect方法。
10: GC.Collect();
12: Console.WriteLine("----------------");
15: serviceScope.ServiceProvider.GetService<IFoobar>();
17: GC.Collect();
19: Console.Read();
21: }
该程序执行之后会在控制台上产生如下所示的输出结果。从这个结果我们可以看出，如果我们使用现有的ServiceProvider来提供所需的服务实例，后者在GC进行垃圾回收之前并不会从内存中释放。如果我们利用现有的ServiceProvider创建一个ServiceScope，并利用它所在的ServiceProvider来提供我们所需的服务实例，GC是可以将其从内存中释放出来的。
4: Foobar.Finalize()
[1] 对于分别采用 Scoped和Singleton模式提供的服务实例，当前ServiceProvider和根ServiceProvider分别具有对它们的引用。如果采用Transient模式，只有服务类型实现了IDisposable接口，当前ServiceProvider才需要对它保持引用以完成对它们的回收，否则没有任何一个ServiceProvider保持对它们的引用。
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实现揭秘【补充漏掉的细节】
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。