1.依赖

在理解依赖注入之前，必须先理解其中的依赖是什么。对于我们开发的程序而言，实际上就是通过不同类型的对象相互协作而构建成的应用，例如在订单类中，就会引用商品类作为某个属性。由于类于类之间存在这种引用关系，在类中就避免不了通过“new”对引用的外部类型进行实例化，对于这种现象就会促使应用程序代码中产生依赖。

对于应用程序代码中存在的这种“依赖关系”，其实通过一种“机械齿轮图”就可以很直观的体会到这种依赖关系所带来的弊端。每个类就像某个齿轮，齿轮之间的啮合传动就像类于类之间的依赖关系。通过“机械齿轮图”的运作场景，我们不难看出这种结构的一种弊端：就是不同的齿轮会相互影响，如果有一个齿轮出了问题，就可能会影响到整个齿轮组的正常运转，对于这种现象，放到应用程序中也是无法避免的现实。

当然，这种依赖对于应用程序带来的后果并不是很直观，通常在.NET Framework时代可能很多项目都存在这种依赖现象，但这种现象并不是一个良好的设计规范，并且会带来下面的问题：

2.粘合剂

3.控制反转和依赖注入

 4.依赖注入的形式

1 public class Person
2 {
3     public IHouse House {get;}
4     public Person(IHouse house)
5     {
6         House=house;
7     }
8 }

使用构造器注入方式需要考虑到一个问题，因为构造函数会存在多个，存在多个构造函数情况下，依赖注入容器又会选择哪一个呢？容器对于这种选择情况，实际上在不同的依赖注入框架种会存在不同的选择策略，所以要根据采用的依赖注入框架而定。那么对于.NET Core而言，它会在所有构造函数的参数列表进行查找，看看哪个构造函数的参数列表是一个“超集”，如果存在“超集”那就会选择这个“超集”所对应的构造函数，对于这个超集的逻辑后续会详细展开，这里只做一个初步的了解即可。

1  public class Person
2  {
3     public IHouse House {get;}
4     public ICar Car {get;}
5     
6     public Person(IHouse house)=>House=house;   
7     public Person(IHouse house,ICar car):this(house)=>car=Car; //超集
8  }

 5.直接依赖和间接依赖

依赖注入在提供某个服务对象时，该服务对象中往往存在着对其他服务对象的依赖，服务对象中的字段或属性是依赖的一种主要体现形式。依赖注入容器会根据这种“依赖链”提供所有间接或直接依赖的服务实例。

上图中Computer类对象依赖于Displayer类，所以Displayer类成了Person类的间接依赖。那么对于依赖注入容器而言，如果要提供Person类的对象，那么它直接和间接依赖的对象Computer、Displayer都会预先被初始化并自动注入到Person类的对象之中。基于这种注入的特点，我们可以简单地理解“依赖注入”属于一种针对依赖字段或属性的自动初始化方式。

存在间接依赖的注意事项

如果直接依赖的服务还存在其他依赖的服务（也就是对于当前提供的服务存在间接依赖），那么直接依赖的服务中需要提供对间接依赖服务注入的构造函数，否则这个间接服务会为NULL。

还是以上面的类图为例，如果要提供Person类的服务，Pseson类中就需要提供对Computer服务注入的构造函数。但是由于直接依赖的Computer类还存在对Displayer类的依赖，即Person的间接依赖，那么Computer类中还必须提供对Displayer服务注入的构造函数，不然这个Displayer间接服务的值会为NULL。

6.依赖注入初体验

我们根据上面的类图作为示例的背景，创建一个ASP.NET Core MVC的应用。针对Home控制器中的依赖项computer字段使用依赖注入的方式创建对象。通常在依赖注入应用场景下，依赖项的类型都定义为接口或基类，所以Home控制器依赖的computer字段类型定义为了一个接口。该接口有一个实现类为DellComputer，它会在服务注册时进行使用，DellComputer类的对象会赋值给computer字段。

 1 namespace DependencyInjectionDemo
 2 {
 3   public interface IComputer
 4     {
 5         string SayHi(); //打招呼
 6     }
 7 
 8     public class Computer : IComputer
 9     {
10         public string SayHi()
11         {
12             return "你好，我是戴尔电脑";
13         }
14     }
15 
16 }

2.在Home控制器中将IComputer接口类型的字段作为依赖项，并使用构造函数作为依赖注入的方式，然后在控制器的Index方法中使用依赖项中的SayHi方法，将该方法的返回值输出到视图。

 1     public class HomeController : Controller
 2     {
 3         private readonly IComputer computer;
 4 
 5         public HomeController(IComputer computer)
 6         {
 7             this.computer = computer;
 8         }
 9 
10         public IActionResult Index()
11         {
12             ViewBag.Msg = this.computer.SayHi();
13             return View();
14         }
15     
16     }

3.在Index视图中输出后台控制器中设置的ViewBag数据，该数据来源于Home控制器的computer字段，也就是它的依赖项。

4.在Startup.cs类的ConfigureServices方法中对Person类所依赖的IComputer服务进行注册。使用AddSingleton进行服务注册，第一个泛型参数为服务类型，第二个泛型参数为服务的实现类。该方法还决定了服务对象的生命周期，对于生命周期后面会有专题进行详细说明，目前无需纠结。此步骤实际上就是告诉容器，我的应用程序需要使用IComputer服务，并且具体的服务实现类是Computer类。

1     public void ConfigureServices(IServiceCollection services)
2         {
3             services.AddSingleton<IComputer, Computer>();
4         }

上图中成功的输出了Home控制器依赖项(computer字段)的方法，并且在Home控制器中使用computer字段并没有通过“new”的形式对其实例化，就实现了对一个引用类型的方法调用。实际操作体验后你会发现，在ASP.NET Core中使用依赖注入并没有什么难点，但这其中的作用其实都是归功于依赖注入框架。

 7.结语