8

ASP.NET Core中的依赖注入（3）: 服务的注册与提供

 3 years ago
source link: https://www.cnblogs.com/artech/p/asp-net-core-di-register.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

在采用了依赖注入的应用中，我们总是直接利用DI容器直接获取所需的服务实例，换句话说，DI容器起到了一个服务提供者的角色，它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。

ServiceProvider与ServiceDescriptor
服务的注册与提供
    利用ServiceProvider来提供服务
    提供一个服务实例的集合
    获取ServiceProvider自身对象
    对泛型的支持

一、ServiceProvider与ServiceDescriptor

我一直觉得优秀的设计首先应该是简单的设计，至少是看起来简单的设计，这就是我们所谓的大道至简。作为一个服务的提供者，ASP.NET Core中的DI容器最终体现为一个IServiceProvider接口，我们将所有实现了该接口的类型及其实例统称为ServiceProvider。如下面的代码片段所示，该接口简单至极，它仅仅提供了唯一个GetService方法，该方法根据提供的服务类型为你提供对应的服务实例。 

   1: public interface IServiceProvider
   2: {
   3:     object GetService(Type serviceType);
   4: }

ASP.NET Core内部真正使用的是一个实现了IServiceProvider接口的内部类型（该类型的名称为“ServiceProvider”），我们不能直接创建该对象，只能间接地通过调用IServiceCollection接口的扩展方法BuildServiceProvider得到它。IServiceCollection接口定义在“Microsoft.Extensions.DependencyInjection”命名空间下，如果没有特别说明，本系列文章涉及到的与ASP.NET Core依赖注入相关的类型均采用此命名空间。 如下面的代码片段所示，IServiceCollection接口实际上代表一个元素为ServiceDescriptor对象的集合，它直接继承了另一个接口IList<ServiceDescriptor>，而ServiceCollection类实现了该接口。 

   1: public static class ServiceCollectionExtensions
   2: {
   3:     public static IServiceProvider BuildServiceProvider(this IServiceCollection services);
   4: }
   5:  
   6: public interface IServiceCollection : IList<ServiceDescriptor>
   7: {}
   8:  
   9: Public class ServiceCollection: IServiceCollection
  10: {
  11:     //省略成员
  12: }

体现为DI容器的ServiceProvider之所以能够根据我们给定的服务类型（一般是一个接口类型）提供一个能够开箱即用的服务实例，是因为我们预先注册了相应的服务描述信息，这些指导ServiceProvider正确实施服务提供操作的服务描述体现为如下一个ServiceDescriptor类型。 

   1: public class ServiceDescriptor
   2: {
   3:     public ServiceDescriptor(Type serviceType, object instance);
   4:     public ServiceDescriptor(Type serviceType, Func<IServiceProvider, object> factory, ServiceLifetime lifetime);
   5:     public ServiceDescriptor(Type serviceType, Type implementationType, ServiceLifetime lifetime);
   6:  
   7:     public Type                                ServiceType {  get; }
   8:     public ServiceLifetime                     Lifetime {  get; }
   9:  
  10:     public Type                                ImplementationType {  get; }
  11:     public object                              ImplementationInstance {  get; }
  12:     public Func<IServiceProvider, object>      ImplementationFactory {  get; }      
  13: }

ServiceDescriptor的ServiceType属性代表提供服务的生命类型，由于标准化的服务一般会定义成接口，所以在绝大部分情况下体现为一个接口类型。类型为ServiceLifetime的属性Lifetime体现了ServiceProvider针对服务实例生命周期的控制方式。如下面的代码片段所示，ServiceLifetime是一个美剧类型，定义其中的三个选项（Singleton、Scoped和Transient）体现三种对服务对象生命周期的控制形式，我们将在本节后续部分对此作专门的介绍。 

   1: public 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的其他属性，则通过方法相应的参数来提供。 

   1: public static class ServiceCollectionExtensions
   2: {
   3:     public static IServiceCollection AddScoped<TService>(this IServiceCollection services) where TService: class;
   4:    //其他AddScoped<TService>重载
   5:  
   6:     public static IServiceCollection AddSingleton<TService>(this IServiceCollection services) where TService: class;
   7:    //其他AddSingleton<TService>重载
   8:  
   9:     public static IServiceCollection AddTransient<TService>(this IServiceCollection services) where TService: class;
  10:     //其他AddTransient<TService>重载
  11: }

对于用作DI容器的ServiceProvider对象来说，我们可以直接调用它的GetService方法根据指定的服务类型获得想用的服务实例。除此之外，服务的提供还可以通过IServiceProvider接口相应的扩展方法来完成。如下面的代码片段所示，扩展方法GetService<T>以泛型参数的形式指定服务的声明类型。至于另外两个扩展方法GetRequiredService和GetRequiredService<T>，如果ServiceProvider不能提供一个具体的服务实例，一个InvalidOperationException异常会被抛出来并提示相应的服务注册信息不足。 

   1: public static class ServiceProviderExtensions
   2: { 
   3:     public static T GetService<T>(this IServiceProvider provider);
   4:     public static object GetRequiredService(this IServiceProvider provider, Type serviceType);
   5:     public static T GetRequiredService<T>(this IServiceProvider provider);
   6: }

利用ServiceProvider来提供服务

接下来采用实例演示的方式来介绍如何利用ServiceCollection进行服务注册，以及如何利用ServiceCollection创建对应的ServiceProvider来提供我们需要的服务实例。我们创建一个ASP.NET Core控制台程序，并在project.json中按照如下的方式添加针对 “Microsoft.Extensions.DepedencyInjection”这个NuGet包的依赖。 

   1: {
   2:   "dependencies": {
   3:     "Microsoft.Extensions.DependencyInjection": "1.0.0-rc1-final" 
   4:   },
   5:   ...
   6: }

我们接下来定义四个服务接口（IFoo、IBar、IBaz和IGux）以及分别实现它们的四个服务类（Foo、Bar、Baz和Gux）如下面的代码片段所示，IGux具有三个只读属性（Foo、Bar和Baz）均为接口类型，并在构造函数中进行初始化。 

   1: public interface IFoo {}
   2: public interface IBar {}
   3: public interface IBaz {}
   4: public interface IGux
   5: {
   6:     IFoo Foo { get; }
   7:     IBar Bar { get; }
   8:     IBaz Baz { get; }
   9: }
  10:  
  11: public class Foo : IFoo {}
  12: public class Bar : IBar {}
  13: public class Baz : IBaz {}
  14: public class Gux : IGux
  15: {
  16:     public IFoo Foo { get; private set; }
  17:     public IBar Bar { get; private set; }
  18:     public IBaz Baz { get; private set; }
  19:  
  20:     public Gux(IFoo foo, IBar bar, IBaz baz)
  21:     {
  22:         this.Foo = foo;
  23:         this.Bar = bar;
  24:         this.Baz = baz;
  25:     }
  26: }   

现在我们在作为程序入口的Main方法中创建了一个ServiceCollection对象，并采用不同的方式完成了针对四个服务接口的注册。具体来说，对于正对服务接口IFoo和IGux的ServiceDescriptor来说，我们指定了代表服务真实类型的ImplementationType属性，而对于针对服务接口IBar和IBaz的ServiceDescriptor来说，我们初始化的则是分别代表服务实例和服务工厂的ImplementationInstance个ImplementationFactory属性。由于我们调用的是AddSingleton方法，所以四个ServiceDescriptor的Lifetime属性均为Singleton。 

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         IServiceCollection services = new ServiceCollection()
   6:             .AddSingleton<IFoo, Foo>()
   7:             .AddSingleton<IBar>(new Bar())
   8:             .AddSingleton<IBaz>(_ => new Baz())
   9:             .AddSingleton<IGux, Gux>();
  10:  
  11:         IServiceProvider serviceProvider = services.BuildServiceProvider();
  12:         Console.WriteLine("serviceProvider.GetService<IFoo>(): {0}",serviceProvider.GetService<IFoo>());
  13:         Console.WriteLine("serviceProvider.GetService<IBar>(): {0}", serviceProvider.GetService<IBar>());
  14:         Console.WriteLine("serviceProvider.GetService<IBaz>(): {0}", serviceProvider.GetService<IBaz>());
  15:         Console.WriteLine("serviceProvider.GetService<IGux>(): {0}", 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均与指定的服务类型不匹配，那么最终返回的是一个空的集合对象。 

   1: public static class ServiceProviderExtensions
   2: {
   3:     public static IEnumerable<T> GetServices<T>(this IServiceProvider provider);
   4:     public static IEnumerable<object> GetServices(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。 

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         IServiceCollection serviceCollection = new ServiceCollection()
   6:              .AddSingleton<IFoobar, Foo>()
   7:              .AddSingleton<IFoobar, Bar>();
   8:  
   9:         IServiceProvider serviceProvider = serviceCollection.BuildServiceProvider();
  10:         Console.WriteLine("serviceProvider.GetService<IFoobar>(): {0}", serviceProvider.GetService<IFoobar>());
  11:  
  12:         IEnumerable<IFoobar> services = serviceProvider.GetServices<IFoobar>();
  13:         int index = 1;
  14:         Console.WriteLine("serviceProvider.GetServices<IFoobar>():");
  15:         foreach (IFoobar foobar in services)
  16:         {
  17:             Console.WriteLine("{0}: {1}", index++, foobar);
  18:         }
  19:     }
  20: }
  21:  
  22: public interface IFoobar {}
  23: public class Foo : IFoobar {}
  24: public 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的这个特性。 

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         IServiceProvider serviceProvider = new ServiceCollection().BuildServiceProvider();
   6:         Debug.Assert(object.ReferenceEquals(serviceProvider, serviceProvider.GetService<IServiceProvider>()));
   7:         Debug.Assert(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），它们在实现类中以构造器注入的方式被初始化。 

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         IServiceProvider serviceProvider = new ServiceCollection()
   6:             .AddTransient<IFoo, Foo>()
   7:             .AddTransient<IBar, Bar>()
   8:             .AddTransient(typeof(IFoobar<,>), typeof(Foobar<,>))
   9:             .BuildServiceProvider();
  10:  
  11:         Console.WriteLine("serviceProvider.GetService<IFoobar<IFoo, IBar>>().Foo: {0}", serviceProvider.GetService<IFoobar<IFoo, IBar>>().Foo);
  12:         Console.WriteLine("serviceProvider.GetService<IFoobar<IFoo, IBar>>().Bar: {0}", serviceProvider.GetService<IFoobar<IFoo, IBar>>().Bar);
  13:     }
  14: }
  15:  
  16: public interface IFoobar<T1, T2>
  17: {
  18:     T1 Foo { get; }
  19:     T2 Bar { get; }
  20: }
  21: public interface IFoo {}
  22: public interface IBar {}
  23:  
  24: public class Foobar<T1, T2> : IFoobar<T1, T2>
  25: {
  26:     public T1 Foo { get; private set; }
  27:     public T2 Bar { get; private set; }
  28:     public Foobar(T1 foo, T2 bar)
  29:     {
  30:         this.Foo = foo;
  31:         this.Bar = bar;
  32:     }
  33: }
  34: public class Foo : IFoo {}
  35: public 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实现揭秘【补充漏掉的细节】


report

Recommend

  • 22
    • www.cnblogs.com 4 years ago
    • Cache

    ASP.NET Core 中间件的使用（二）：依赖注入的使用

    写在前面 上一篇大家已经粗略接触了解到.NET Core中间件的使用：ASP .Net Core 中间件的使用（一）：搭建静态文件服务器/访问指定文件，

  • 8
    • www.cnblogs.com 4 years ago
    • Cache

    [ASP.NET Core 3框架揭秘] 依赖注入[3]：依赖注入模式

    IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架之中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在前面介绍的模板方法、工厂方法和抽象工...

  • 9
    • www.cnblogs.com 3 years ago
    • Cache

    ASP.NET Core中的依赖注入（1）：控制反转（IoC）

    ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务，为了方便对这些组件进行定制，ASP.NET通过定义接口的方式对它们进行了“标准化”，我们将这些标准化的组件称为服务，ASP.NET在内部专门维护了一个DI容器来提供所需...

  • 5
    • www.cnblogs.com 3 years ago
    • Cache

    [ASP.NET Core 3框架揭秘] 依赖注入[2]：IoC模式

    正如我们在《依赖注入：控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC不仅与面向对象没有必然的联系，它自身甚至算不上是一种设计模式。一般来讲...

  • 11
    • www.cnblogs.com 3 years ago
    • Cache

    ASP.NET Core中的依赖注入（2）：依赖注入（DI）

    IoC主要体现了这样一种设计思想：通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用，同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在

  • 8
    • www.cnblogs.com 2 years ago
    • Cache

    【ASP.NET Core】选项类的依赖注入 - 东邪独孤

    【ASP.NET Core】选项类的依赖注入 咱们继续上一个话题...

  • 8
    • www.cnblogs.com 2 years ago
    • Cache

    ASP.NET Core - 依赖注入(一) - 啊晚

    1. Ioc 与 DI Ioc 和DI 这两个词大家都应该比较熟悉，这两者已经在各种开发语言各种框架中普遍使用，成为框架中的一种基本设施了。 Ioc 是控制反转， Inversion of Control 的缩写，DI 是依赖注入，Inject Dependency 的缩写。...

  • 12
    • www.cnblogs.com 2 years ago
    • Cache

    ASP.NET Core - 依赖注入(二) - 啊晚

    .NET Core 依赖注入的基本用法 话接上篇，这一章介绍 .NET Core 框架自带的轻量级 Ioc 容器下服务使用的一些知识点，大家可以先看看上一篇文章 [ASP.NET Core - 依赖注入(一)] 2.3 服务...

  • 6
    • www.cnblogs.com 2 years ago
    • Cache

    ASP.NET Core - 依赖注入(四) - 啊晚

    4. ASP.NET Core默认服务 之前讲了中间件，实际上一个中间件要正常进行工作，通常需要许多的服务配合进行，而中间件中的服务自然也是通过 Ioc 容器进行注册和注入的。前面也讲到，按照约定中间件的封装一般会提供一个 User{Midd...

  • 7
    • www.cnblogs.com 1 year ago
    • Cache

    【ASP.NET Core】在 Mini-API 中注入服务 - 东邪独孤

    【ASP.NET Core】在 Mini-API 中注入服务 经过版本...

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK