ASP.NET Core依赖注入系列教程之服务的注册与提供

前言

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

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

一、ServiceProvider与ServiceDescriptor

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

 public interface IServiceProvider
 {
 object GetService(Type serviceType);
 }

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

 public static class ServiceCollectionExtensions
 {
 public static IServiceProvider BuildServiceProvider(this IServiceCollection services);
 }

 public interface IServiceCollection : IList<ServiceDescriptor>
 {}

 Public class ServiceCollection: IServiceCollection
 {
 //省略成员
 }

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

 public class ServiceDescriptor
 {
 public ServiceDescriptor(Type serviceType, object instance);
 public ServiceDescriptor(Type serviceType, Func<IServiceProvider, object> factory, ServiceLifetime lifetime);
 public ServiceDescriptor(Type serviceType, Type implementationType, ServiceLifetime lifetime);

 public Type ServiceType { get; }
 public ServiceLifetime Lifetime { get; }

 public Type ImplementationType { get; }
 public object ImplementationInstance { get; }
 public Func<IServiceProvider, object> ImplementationFactory { get; }
 }

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

 public enum ServiceLifetime
 {
 Singleton,
 Scoped,
 Transient
 }

3-10对于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的其他属性,则通过方法相应的参数来提供。

 public static class ServiceCollectionExtensions
 {
 public static IServiceCollection AddScoped<TService>(this IServiceCollection services) where TService: class;
 //其他AddScoped<TService>重载

 public static IServiceCollection AddSingleton<TService>(this IServiceCollection services) where TService: class;
 //其他AddSingleton<TService>重载

 public static IServiceCollection AddTransient<TService>(this IServiceCollection services) where TService: class;
 //其他AddTransient<TService>重载
 }

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

 public static class ServiceProviderExtensions
 {
 public static T GetService<T>(this IServiceProvider provider);
 public static object GetRequiredService(this IServiceProvider provider, Type serviceType);
 public static T GetRequiredService<T>(this IServiceProvider provider);
 }

利用ServiceProvider来提供服务

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

 {
 "dependencies": {
 "Microsoft.Extensions.DependencyInjection": "1.0.0-rc1-final"
 },
 ...
 }

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

 public interface IFoo {}
 public interface IBar {}
 public interface IBaz {}
 public interface IGux
 {
 IFoo Foo { get; }
 IBar Bar { get; }
 IBaz Baz { get; }
 }

 public class Foo : IFoo {}
 public class Bar : IBar {}
 public class Baz : IBaz {}
 public class Gux : IGux
 {
 public IFoo Foo { get; private set; }
 public IBar Bar { get; private set; }
 public IBaz Baz { get; private set; }

 public Gux(IFoo foo, IBar bar, IBaz baz)
 {
 this.Foo = foo;
 this.Bar = bar;
 this.Baz = baz;
 }
 } 

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

 class Program
 {
 static void Main(string[] args)
 {
 IServiceCollection services = new ServiceCollection()
 .AddSingleton<IFoo, Foo>()
 .AddSingleton<IBar>(new Bar())
 .AddSingleton<IBaz>(_ => new Baz())
 .AddSingleton<IGux, Gux>();

 IServiceProvider serviceProvider = services.BuildServiceProvider();
 Console.WriteLine("serviceProvider.GetService<IFoo>(): {0}",serviceProvider.GetService<IFoo>());
 Console.WriteLine("serviceProvider.GetService<IBar>(): {0}", serviceProvider.GetService<IBar>());
 Console.WriteLine("serviceProvider.GetService<IBaz>(): {0}", serviceProvider.GetService<IBaz>());
 Console.WriteLine("serviceProvider.GetService<IGux>(): {0}", serviceProvider.GetService<IGux>());
 }
 }

接下来我们调用ServiceCollection对象的扩展方法BuildServiceProvider得到对应的ServiceProvider对象,然后调用其扩展方法GetService<T>分别获得针对四个接口的服务实例对象并将类型名称其输出到控制台上。运行该程序之后,我们会在控制台上得到如下的输出结果,由此印证ServiceProvider为我们提供了我们期望的服务实例。

 serviceProvider.GetService<IFoo>(): Foo
 serviceProvider.GetService<IBar>(): Bar
 serviceProvider.GetService<IBaz>(): Baz
 serviceProvider.GetService<IGux>(): Gux

提供一个服务实例的集合

如果我们在调用GetService方法的时候将服务类型指定为IEnumerable<T>,那么返回的结果将会是一个集合对象。除此之外, 我们可以直接调用IServiceProvider如下两个扩展方法GetServeces达到相同的目的。在这种情况下,ServiceProvider将会利用所有与指定服务类型相匹配的ServiceDescriptor来提供具体的服务实例,这些均会作为返回的集合对象的元素。如果所有的ServiceDescriptor均与指定的服务类型不匹配,那么最终返回的是一个空的集合对象。

 public static class ServiceProviderExtensions
 {
 public static IEnumerable<T> GetServices<T>(this IServiceProvider provider);
 public static IEnumerable<object> GetServices(this IServiceProvider provider, Type serviceType);
 }

值得一提的是,如果ServiceProvider所在的ServiceCollection包含多个具有相同服务类型(对应ServiceType属性)的ServiceDescriptor,当我们调用GetService方法获取单个服务实例的时候,只有最后一个ServiceDescriptor才是有效的,至于其他的ServiceDescriptor,它们只有在获取服务集合的场景下才有意义。

我们通过一个简单的实例来演示如何利用ServiceProvider得到一个包含多个服务实例的集合。我们在一个控制台应用中定义了如下一个服务接口IFoobar,两个服务类型Foo和Bar均实现了这个接口。在作为程序入口的Main方法中,我们将针针对服务类型Foo和Bar的两个ServiceDescriptor添加到创建的ServiceCollection对象中,这两个ServiceDescriptor对象的ServiceType属性均为IFoobar。

 class Program
 {
 static void Main(string[] args)
 {
  IServiceCollection serviceCollection = new ServiceCollection()
  .AddSingleton<IFoobar, Foo>()
  .AddSingleton<IFoobar, Bar>();

  IServiceProvider serviceProvider = serviceCollection.BuildServiceProvider();
  Console.WriteLine("serviceProvider.GetService<IFoobar>(): {0}", serviceProvider.GetService<IFoobar>());

  IEnumerable<IFoobar> services = serviceProvider.GetServices<IFoobar>();
  int index = 1;
  Console.WriteLine("serviceProvider.GetServices<IFoobar>():");
  foreach (IFoobar foobar in services)
  {
  Console.WriteLine("{0}: {1}", index++, foobar);
  }
 }
 }

 public interface IFoobar {}
 public class Foo : IFoobar {}
 public class Bar : IFoobar {}

在调用ServiceCollection对象的扩展方法BuildServiceProvider得到对应的ServiceProvider对象之后,我们先调用其GetService<T>方法以确定针对服务接口IFoobar得到的服务实例的真实类型就是是Foo还是Bar。接下来我们调用ServiceProvider的扩展方法GetServices<T>获取一组针对服务接口IFoobar的服务实例并将它们的真是类型打印在控制台上。该程序运行后将会在控制台上生成如下的输出结果。

 serviceProvider.GetService<IFoobar>(): Bar
 serviceProvider.GetServices<IFoobar>():
 1: Foo
 2: Bar

获取ServiceProvider自身对象

对于ServiceProvider的服务提供机制来说,还有一个小小的细节值得我们关注,那就是当我们调用GetService或者GetRequiredService方法的时候若将服务类型设定为IServiceProvider,那么得到的对象实际上就是ServiceProvider自身这个对象。与之同理,调用GetServices方法将会返回一个包含自身的集合。如下所示的代码片段体现了ServiceProvider的这个特性。

 class Program
 {
  static void Main(string[] args)
  {
   IServiceProvider serviceProvider = new ServiceCollection().BuildServiceProvider();
   Debug.Assert(object.ReferenceEquals(serviceProvider, serviceProvider.GetService<IServiceProvider>()));
   Debug.Assert(object.ReferenceEquals(serviceProvider, serviceProvider.GetServices<IServiceProvider>().Single()));
  }
 }

对泛型的支持

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
 {
  static void Main(string[] args)
  {
   IServiceProvider serviceProvider = new ServiceCollection()
    .AddTransient<IFoo, Foo>()
    .AddTransient<IBar, Bar>()
    .AddTransient(typeof(IFoobar<,>), typeof(Foobar<,>))
    .BuildServiceProvider();

   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);
  }
 }

 public interface IFoobar<T1, T2>
 {
  T1 Foo { get; }
  T2 Bar { get; }
 }
 public interface IFoo {}
 public interface IBar {}

 public class Foobar<T1, T2> : IFoobar<T1, T2>
 {
  public T1 Foo { get; private set; }
  public T2 Bar { get; private set; }
  public Foobar(T1 foo, T2 bar)
  {
   this.Foo = foo;
   this.Bar = bar;
  }
 }
 public class Foo : IFoo {}
 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属性类型输出于控制台上作为验证。该程序执行之后将会在控制台上产生下所示的输出结果。

 serviceProvider.GetService<IFoobar<IFoo, IBar>>().Foo: Foo
 serviceProvider.GetService<IFoobar<IFoo, IBar>>().Bar: Bar

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • 详解ASP.NET Core 中的框架级依赖注入

    1.ASP.NET Core 中的依赖注入 此示例展示了框架级依赖注入如何在 ASP.NET Core 中工作. 其简单但功能强大,足以完成大部分的依赖注入工作.框架级依赖注入支持以下 scope: Singleton - 总是返回相同的实例 Transient - 每次都返回新的实例 Scoped - 在当前(request)范围内返回相同的实例 假设我们有两个要通过依赖注入来进行工作的工件: PageContext - 自定义请求上下文 Settings - 全局应用程序设置 这两个都是非常

  • ASP.NET Core依赖注入系列教程之控制反转(IoC)

    前言 ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务,为了方便对这些组件进行定制,ASP.NET通过定义接口的方式对它们进行了"标准化",我们将这些标准化的组件称为服务,ASP.NET在内部专门维护了一个DI容器来提供所需的服务.要了解这个DI容器以及现实其中的服务提供机制,我们先得知道什么是DI(Dependence Injection),而一旦我们提到DI,又不得不说IoC(Inverse of Control). 一.流程控

  • 详解ASP.NET Core 在 JSON 文件中配置依赖注入

    前言 在上一篇文章中写了如何在MVC中配置全局路由前缀,今天给大家介绍一下如何在在 json 文件中配置依赖注入. 在以前的 ASP.NET 4+ (MVC,Web Api,Owin,SingalR等)时候,都是提供了专有的接口以供使用第三方的依赖注入组件,比如我们常用的会使用 Autofac.Untiy.String.Net 等,这些第三放依赖注入组件基本上都提供了一套配置注入或者配置生命周期的方式,除了直接配置到类里面之外,还提供了要么使用 xml 文件,要么使用 json 等,那么在新的

  • 扩展ASP.NET MVC三层框架且使用StructureMap实现依赖注入1-Model层

    本篇文章将向大家介绍如何添加Service和Repository层并且使用StructureMap把Service层注入到Controller,把Repository注入到Service层.Service层主要是我们的业务逻辑层,这一层不和底层的Database打交道,和Database打交道的是Repository数据持久层.本篇文章通过使用StructureMap依赖注入使Controller,Service,Repository三层的耦合度降到最低. 本系统使用NorthWind开源数据,

  • 解读ASP.NET 5 & MVC6系列教程(7):依赖注入

    在前面的章节(Middleware章节)中,我们提到了依赖注入功能(Dependency Injection),ASP.NET 5正式将依赖注入进行了全功能的实现,以便开发人员能够开发更具弹性的组件程序,MVC6也利用了依赖注入的功能重新对Controller和View的服务注入功能进行了重新设计:未来的依赖注入功能还可能提供更多的API,所有如果还没有开始接触依赖注入的话,就得好好学一下了. 在之前版本的依赖注入功能里,依赖注入的入口有MVC中的IControllerFactory和Web A

  • ASP.NET Core依赖注入系列教程之服务的注册与提供

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

  • 详解asp.net core 依赖注入

    前言 好久没有写微博了,因为前段时间由于家庭原因决定从工作了3年多的北京转移到上海去.依赖注入在学习net core的时候也有写过类似的东西,只是实践的较少,结果来到上海新公司系统框架涉及到了这块知识点,所以在了解完自己的项目之后决定做一些相关的总结.接下来就让我们先来了解hewi依赖注入. 什么是依赖注入 依赖注入,全称是"依赖注入到容器", 容器(IOC容器)是一个设计模式,它也是个对象,你把某个类(不管有多少依赖关系)放入这个容器中,可以"解析"出这个类的实例

  • 理解ASP.NET Core 依赖注入(Dependency Injection)

    目录 依赖注入 什么是依赖注入 依赖注入有什么好处 ASP.NET Core内置的依赖注入 服务生存周期 服务释放 TryAdd{Lifetime}扩展方法 解析同一服务的多个不同实现 Replace && Remove 扩展方法 Autofac 服务解析和注入 构造函数注入 方法注入 属性注入 一些注意事项 框架默认提供的服务 依赖注入 什么是依赖注入 简单说,就是将对象的创建和销毁工作交给DI容器来进行,调用方只需要接收注入的对象实例即可. 微软官方文档-DI 依赖注入有什么好处 依赖

  • ASP.NET Core  依赖注入框架的使用

    目录 一.IoC框架 二.IoC-Autofac 三..NET Core中自带DI的使用 四.Autofac 使用 五.批量注入 前言: 还记得上篇文章中ASP.NET Core 依赖注入详细最后提及到,假如服务越来越多怎么处理呢,本篇文章将会带来解决办法.这篇是接上一篇文章的,概念方面的可以参考上一篇文章. 一.IoC框架 先说说常见的Ioc框架吧. Autofac: 目前net用的比较多,好多大佬的项目比较优先选择的框架. Ninject: 已经很少用了,还时在很早的文章中见过. Unity

  • ASP.NET Core 依赖注入详细

    目录 一.控制反转 二.好莱坞法则 三.流程控制 四.三种依赖注入方式 1.构造器注入 2.属性注入 3.方法注入 五.生命周期 六.ASP.Net Core 中自带的注入 前言: ASP.NET Core 应用在启动过程中会依赖各种组件提供服务,而这些组件会以接口的形式标准化,这些组件这就是我们所说的服务,ASP.NET Core框架建立在一个底层的依赖注入框架之上,它使用容器提供所需的服务.要了解依赖注入容器以及它的机制,我们需要了解什么是依赖注入. 一.控制反转 说道依赖注入就不得不提控制

  • ASP.NET Core依赖注入详解

    目录 一.什么是依赖注入 二.使用框架提供的服务 三.注册服务 四.生命周期 五.请求服务 六.设计你的依赖服务 ASP.NET Core的底层设计支持和使用依赖注入.ASP.NET Core应用程序可以利用内置的框架服务将它们注入到启动类的方法中,并且应用程序服务能够配置注入.由ASP.NET Core提供的默认服务容器提供了最小功能集,并不是要取代其它容器. 一.什么是依赖注入 依赖注入(Dependency injection,DI)是一种实现对象及其合作者或依赖项之间松散耦合的技术.将类

  • ASP.NET Core依赖注入(DI)讲解

    ASP.NET Core的底层设计支持和使用依赖注入.ASP.NET Core 应用程序可以利用内置的框架服务将服务注入到启动类的方法中,并且应用程序服务也可以配置注入.由ASP.NET Core 提供的默认服务容器提供了最小功能集,并不是取代其他容器. 1.浅谈依赖注入 依赖注入(Dependency injection,DI)是一种实现对象和依赖者之间松耦合的技术,将类用来执行其操作的这些对象以注入的方式提供给该类,而不是直接实例化依赖项或者使用静态引用.一般情况,类会通过构造函数声明器2依

  • ASP.NET Core依赖关系注入

    1.前言 面向对象设计(OOD)里有一个重要的思想就是依赖倒置原则(DIP),并由该原则牵引出依赖注入(DI).控制反转(IOC)及其容器等老生常谈的概念,初学者很容易被这些概念搞晕(包括我在内),在学习Core依赖注入服务之前,下面让我们先了解下依赖倒置原则(DIP).依赖注入(DI).控制反转(IOC)等概念,然后再深入学习Core依赖注入服务. 2.依赖倒置原则(DIP) 高层模块不依赖于低层模块的实现,而低层模块依赖于高层模块定义的接口.通俗来讲,就是高层模块定义接口,低层模块负责实现.

  • ASP.Net Core MVC基础系列之环境设置

    上一节我们介绍了中间件的基本使用, 这一节我们讲一讲.Net Core的环境设置, 以及根据不同的环境加载不同的配置信息 PS: 由于最近一直比较忙, 一直没抽时间更新这个系列, 最近居多的博友催我, 所以继续挤挤时间更新这个系列, 感谢大家的对本系列教程的喜欢和支持. 在实际开发中, 我们的系统往往会是至少两个以上的运行环境, 最基本的就是, 开发环境和运营环境, 体系完整的公司, 还会有测试环境, 预发布环境, 和一些自定义环境等等, 这些环境使用的配置或是一些参数肯定是不一样的, 我们不可

随机推荐