【 .NET Core 3.0 】框架之九 || 依赖注入 与 IoC

本文有配套视频：https://www.bilibili.com/video/av58096866/?p=5

前言

1、重要：如果你实现了解耦，也就是 api 层只引用了 IService 和 IRepository 的话，那每次修改 service 层，都需要清理解决方案，重新编译项目，因为这个时候你的api层的dll，还是之前未修改的代码。 2、重要+ ：请注意，依赖注入的目的不是为了解耦，依赖注入是为了控制反转，通俗来说，就是不用我们自己去 new 服务实例了，所以大家不需要一定去解耦（比如下文说到的我没有引用 Service层 和 Repository层），我下一个DDD系列，依赖注入就没有解耦，因为我用的是自带的注入，不是Autofac的反射dll ，我解耦的目的，是为了让大家更好的理解，服务是怎么注入到宿主容器里的。

说接上文，上回说到了《八 || API项目整体搭建 6.3 异步泛型+依赖注入初探》，后来的标题中，我把仓储两个字给去掉了，因为好像大家对这个模式很有不同的看法，嗯~可能还是我学艺不精，没有说到其中的好处，现在在学DDD领域驱动设计相关资料，有了好的灵感再给大家分享吧。

　　虽然项目整体可以运行了，但是我还有几个小知识点要说下，主要是1、依赖注入和AOP相关知识；2、跨域代理等问题（因为Vue是基于Node开发的，与后台API接口不在同一个地址）；3、实体类的DTO相关小问题；4、Redis缓存等；5、部署服务器中的各种坑；虽然都是很小的知识点，我还是都下给大家说下的，好啦，开始今天的讲解；

零、今天完成的绿色部分

一、依赖注入的理解和思考

更新(19-04-17)：如果想好好的理解依赖注入，可以从以下几个方面入手：

1、项目之间引用是如何起作用的，比如为啥 api 层只是引用了 service 层，那为啥也能使用 repository 和 model 等多层的类？ 2、项目在启动的时候，也就是运行时，是如何动态 获取和访问 每一个对象的实例的？也就是 new 的原理 3、项目中有 n 个类，对应 m 个实例等，那这些服务，都放在了哪里？肯定每一个项目都有专属自己的一块。如果项目不启动的话，内存里肯定是没有这些服务的。 4、使用接口（面向抽象）的好处？ 5、在项目后期，如何业务需要要全部修改接口的实现类，比如想把 IA = new A()；全部 改成 IA = new B(); 6、反射的重要性，为什么要用到反射 dll ？

如果这些每一条自己都能说清楚，那肯定就知道依赖注入是干啥的了。

说到依赖，我就想到了网上有一个例子，依赖注入和工厂模式中的相似和不同：

(1)原始社会里，没有社会分工。须要斧子的人(调用者)仅仅能自己去磨一把斧子(被调用者)。相应的情形为:软件程序里的调用者自己创建被调用者。 (2)进入工业社会，工厂出现。斧子不再由普通人完毕，而在工厂里被生产出来，此时须要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。相应软件程序的简单工厂的设计模式。 (3)进入“按需分配”社会，需要斧子的人不需要找到工厂，我们只需要去干活就行，斧子已经给我们自动准备好了，直接用就可以了。

首先，我们需要了解下什么是控制反转IOC，举个栗子，我在之前开发简单商城的时候，其中呢，订单模块，有订单表，那里边肯定有订单详情表，而且呢订单详情表中还有商品信息表，商品信息表还关联了价格规格表，或者其他的物流信息，商家信息，当然，我们可以放到一个大表里，可是你一定不会这么做，因为太庞大，所以必定分表，那必定会出现类中套类的局面，这就是依赖，比如上边的，订单表就依赖了详情表，我们在实例化订单实体类的时候，也需要手动实例详情表，当然，EF框架中，会自动生成。不过倘若有一个程序员把详情表实体类改错了，那订单表就崩溃了，哦不！我是遇到过这样的情景。

怎么解决这个问题呢，就出现了控制反转。网上看到一个挺好的讲解：

1、没有引入IOC之前，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，A直接使用new关键字创建B的实例，程序高度耦合，效率低下，无论是创建还是使用B对象，控制权都在自己手上。 2、软件系统在引入IOC容器之后，这种情形就完全改变了，由于IOC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。 3、依赖注入，是指程序运行过程中，如果需要调用另一个对象协助时，无须在代码中创建被调用者，而是依赖于外部的注入。Spring的依赖注入对调用者和被调用者几乎没有任何要求，完全支持对POJO之间依赖关系的管理。依赖注入通常有两种: ·设值注入。 ·构造注入。 这个就是依赖注入的方式。

什么是控制反转（IoC）

Inversion of Control，英文缩写为IoC，不是什么技术，而是一种设计思想。

简单来说就是把复杂系统分解成相互合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展。IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦，如下图：

大家看到了吧，由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“黏合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“黏合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“黏合剂”的由来。

我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：

我们现在看到的画面，就是我们要实现整个系统所需要完成的全部内容。这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现A的时候，根本无须再去考虑B、C和D了，对象之间的依赖关系已经降低到了最低程度。所以，如果真能实现IOC容器，对于系统开发而言，这将是一件多么美好的事情，参与开发的每一成员只要实现自己的类就可以了，跟别人没有任何关系！

在上面文章中，我们已经了解到了，什么是依赖倒置、控制反转（IOC），什么是依赖注入（DI），网上这个有很多很多的讲解，我这里就不说明了，其实主要是见到这样的，就是存在依赖

public class A : D
{

    public A(B b)
    {
        // do something   
    }
    C c = new C();
}

就比如我们的项目中的BlogController，只要是通过new 实例化的，都是存在依赖

public async Task<List<Advertisement>> Get(int id)
{
    IAdvertisementServices advertisementServices = new AdvertisementServices();
    return await advertisementServices.Query(d => d.Id == id);
}

使用依赖注入呢，有以下优点：

• 传统的代码，每个对象负责管理与自己需要依赖的对象，导致如果需要切换依赖对象的实现类时，需要修改多处地方。同时，过度耦合也使得对象难以进行单元测试。
• 依赖注入把对象的创造交给外部去管理,很好的解决了代码紧耦合（tight couple）的问题，是一种让代码实现松耦合（loose couple）的机制。
• 松耦合让代码更具灵活性，能更好地应对需求变动，以及方便单元测试。

举个栗子，就是关于日志记录的

日志记录：有时需要调试分析，需要记录日志信息，这时可以采用输出到控制台、文件、数据库、远程服务器等；假设最初采用输出到控制台，直接在程序中实例化ILogger logger = new ConsoleLogger()，但有时又需要输出到别的文件中，也许关闭日志输出，就需要更改程序，把ConsoleLogger改成FileLogger或者NoLogger， new FileLogger()或者new SqlLogger() ，此时不断的更改代码，就显得心里不好了，如果采用依赖注入，就显得特别舒畅。

二、常见的IoC框架有哪些

1、Autofac+原生

我常用的还是原生注入和 Autofac 注入。

Autofac：貌似目前net下用的最多吧 Ninject：目前好像没多少人用了 Unity：也是较为常见 微软 core 自带的 DI

其实.Net Core 有自己的轻量级的IoC框架，

ASP.NET Core本身已经集成了一个轻量级的IOC容器，开发者只需要定义好接口后，在Startup.cs的ConfigureServices方法里使用对应生

命周期的绑定方法即可，常见方法如下

services.AddTransient<IApplicationService,ApplicationService>//服务在每次请求时被创建，它最好被用于轻量级无状态服务（如我们的Repository和ApplicationService服务） services.AddScoped<IApplicationService,ApplicationService>//服务在每次请求时被创建，生命周期横贯整次请求 services.AddSingleton<IApplicationService,ApplicationService>//Singleton（单例） 服务在第一次请求时被创建（或者当我们在ConfigureServices中指定创建某一实例并运行方法），其后的每次请求将沿用已创建服务。如果开发者的应用需要单例服务情景，请设计成允许服务容器来对服务生命周期进行操作，而不是手动实现单例设计模式然后由开发者在自定义类中进行操作。

当然.Net Core自身的容器还是比较简单，如果想要更多的功能和扩展，还是需要使用上边上个框架。

2、三种注入的生命周期

权重：

AddSingleton→AddTransient→AddScoped

AddSingleton的生命周期：

项目启动-项目关闭 相当于静态类 只会有一个

AddScoped的生命周期：

请求开始-请求结束 在这次请求中获取的对象都是同一个

AddTransient的生命周期：

请求获取-（GC回收-主动释放） 每一次获取的对象都不是同一个

这里来个简单的小DEMO：

1、定义四个接口，并分别对其各自接口实现，目的是测试Singleton，Scope，Transient三种，以及最后的 Service 服务：

 public interface ISingTest
    {
        int Age { get; set; }
        string Name { get; set; }
    }

 public class SingTest: ISingTest
 {
     public int Age { get; set; }
     public string Name { get; set; }
 }

//--------------------------

 public interface ISconTest
 {
     int Age { get; set; }
     string Name { get; set; }
 }
  public class SconTest: ISconTest
  {
      public int Age { get; set; }
      public string Name { get; set; }
  }

//--------------------------
 public interface ITranTest
 {
     int Age { get; set; }
     string Name { get; set; }
 }
  public class TranTest: ITranTest
  {
      public int Age { get; set; }
      public string Name { get; set; }
  }

//-----------------------
public interface IAService
{
    void RedisTest();
}

 public class AService : IAService
 {
     private ISingTest sing; ITranTest tran; ISconTest scon;
     public AService(ISingTest sing, ITranTest tran, ISconTest scon)
     {
         this.sing = sing;
         this.tran = tran;
         this.scon = scon;
     }
     public void RedisTest()
     {

     }
 }

2、项目注入

3、控制器调用

 private ISingTest sing; ITranTest tran; ISconTest scon; IAService aService;
  public ValuesController(ISingTest sing, ITranTest tran, ISconTest scon, IAService aService)
  {
      this.sing = sing;
      this.tran = tran;
      this.scon = scon;
      this.aService = aService;
  }

  // GET api/values
  [HttpGet]
  public ActionResult<IEnumerable<string>> SetTest()
  {
      sing.Age = 18;
      sing.Name = "小红";

      tran.Age = 19;
      tran.Name = "小明";

      scon.Age = 20;
      scon.Name = "小蓝";

      aService.RedisTest();


      return new string[] { "value1", "value2" };
  }

  // GET api/values/5
  [HttpGet("{id}")]
  public ActionResult<string> Get(int id)
  {
      return "value";
  }

4、开始测试，三种注入方法出现的情况

请求SetTest // GET api/values

AddSingleton的对象没有变

AddScoped的对象没有变化

AddTransient的对象发生变化

------------------------------------------------------------

请求 // GET api/values/5

AddSingleton的对象没有变

AddScoped的对象发生变化

AddTransient的对象发生变化

注意：

由于AddScoped对象是在请求的时候创建的

所以不能在AddSingleton对象中使用

甚至也不能在AddTransient对象中使用

所以权重为

AddSingleton→AddTransient→AddScoped

不然则会抛如下异常

三、较好用的IoC框架使用——Autofac

首先呢，我们要明白，我们注入是要注入到哪里——Controller API层。然后呢，我们看到了在接口调用的时候，如果需要其中的方法，需要using两个命名空间

[HttpGet("{id}", Name = "Get")]
public async Task<List<Advertisement>> Get(int id)
{            
     //需要引用两个命名空间Blog.Core.IServices;Blog.Core.Services;
     IAdvertisementServices advertisementServices = new AdvertisementServices();
     return await advertisementServices.Query(d => d.Id == id);
}

接下来我们就需要做处理：

1、引入nuget包

在Nuget中引入两个：Autofac.Extras.DynamicProxy（Autofac的动态代理，它依赖Autofac，所以可以不用单独引入Autofac）、Autofac.Extensions.DependencyInjection（Autofac的扩展），注意是最新版本的。

 <PackageReference Include="Autofac.Extensions.DependencyInjection" Version="5.0.0" />
 <PackageReference Include="Autofac.Extras.DynamicProxy" Version="4.5.0" />

2、配置容器，注入服务

在startup.cs 文件中，增加一个方法，用来配置Autofac 服务容器

首先我们创建一个接口和对应的实现类：

 public interface IAdvertisementServices
 {
     int Test();
 }

 public class AdvertisementServices : IAdvertisementServices
 {
     public int Test()
     {
         return 1;
     }
 }

然后将这个服务，注入到Autofac 容器里：

 public void ConfigureContainer(ContainerBuilder builder)
 {

     var basePath = Microsoft.DotNet.PlatformAbstractions.ApplicationEnvironment.ApplicationBasePath;

     //直接注册某一个类和接口
     //左边的是实现类，右边的As是接口
     builder.RegisterType<AdvertisementServices>().As<IAdvertisementServices>();


     //注册要通过反射创建的组件
     var servicesDllFile = Path.Combine(basePath, "Blog.Core.Services.dll");
     var assemblysServices = Assembly.LoadFrom(servicesDllFile);

     builder.RegisterAssemblyTypes(assemblysServices)
               .AsImplementedInterfaces()
               .InstancePerLifetimeScope()
               .EnableInterfaceInterceptors();

 }

这个时候我们就把 AdvertisementServices的new 实例化过程注入到了Autofac容器中，

这个时候要看明白，前边的是实现类，后边的是接口，顺序不要搞混了。

3、使用服务工厂，将Autofac容器添加到Host

为什么要这么做呢，从上边你也应该看到了，我们现在仅仅是配置了服务和容器，还没有添加到我们的项目宿主里，那我们的controller就拿不到相应的服务。

我们需要在 Program.cs 文件中，配置 UseServiceProviderFactory

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
    .UseServiceProviderFactory(new AutofacServiceProviderFactory()) //<--NOTE THIS
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

4、使用构造函数方式来注入

依赖注入有三种方式（构造函数注入、属性注入和方式注入），我们平时基本都是使用其中的构造函数方式实现注入，

大家还记得默认控制器 WeatherForecastController 么，当时我们说到了，已经有了一个依赖注入的用法，就是 ILogger，那现在我们继续注入，

 private readonly ILogger<WeatherForecastController> _logger;
 private readonly IAdvertisementServices advertisementServices;

 public WeatherForecastController(ILogger<WeatherForecastController> logger, IAdvertisementServices advertisementServices)
 {
     _logger = logger;
     this.advertisementServices = advertisementServices;
 }

 /// <summary>
 /// 获取接口数据
 /// </summary>
 /// <returns></returns>
 [HttpGet]
 public string[] Get()
 {
     var ads = advertisementServices.Test();
     return Summaries;
 }

5、效果调试，已经成功

然后运行调试，发现在断点刚进入的时候，接口已经被实例化了，达到了注入的目的。

注意：这里经常会遇到一个错误：None of the constructors found with ........，

查看你的service服务，是不是用了其他的仓储repository，但是又缺少了构造函数。

如果没有问题，大家就需要想想，除了 Autofac 还有没有其他的不用第三方框架的注入方法呢？聪明如你，netcore 还真自带了注入扩展。

6、NetCore 自带的注入实现效果

当然，我们用 Asp.net core 自带的注入方式也是可以的，也挺简单的，这里先说下使用方法：

 // 注入 service
 services.AddScoped<IAdvertisementServices, AdvertisementServices>();

这个时候，我们发现已经成功的注入了，而且特别简单，那为啥还要使用 Autofac 这种第三方扩展呢，我们想一想，上边我们仅仅是注入了一个 Service ，但是项目中有那么多的类，都要一个个手动添加么，多累啊，答案当然不是滴~

四、整个 dll 程序集的注入

1、服务程序集注入方式 —— 未解耦

通过反射将 Blog.Core.Services 和 Blog.Core.Repository 两个程序集的全部方法注入

修改如下代码，注意这个时候需要在项目依赖中，右键，添加引用 Blog.Core.Services 层和 Repository 层 到项目中，如下图，这个时候我们的程序依赖了具体的服务：

核心代码如下，注意这里是 Load 模式（程序集名），还是在startup.cs 文件中，配置Autofac容器。

 public void ConfigureContainer(ContainerBuilder builder)
 {

     var assemblysServices = Assembly.Load("Blog.Core.Services");
   
     builder.RegisterAssemblyTypes(assemblysServices)
               .AsImplementedInterfaces()
               .InstancePerLifetimeScope()
               .EnableInterfaceInterceptors();
 }

其他不变，运行项目，一切正常，换其他接口也可以，具体的就不细说。

到这里，Autofac依赖注入已经完成，基本的操作就是这样，不过可能你还没有真正体会到注入的好处，挑战下吧，看看下边的内容，将层级进行解耦试试！

2、程序集注入 —— 实现层级解耦

这是一个学习的思路，大家要多想想，可能会感觉无聊或者没用，但是对理解项目启动和加载，还是很有必要的。

1、项目最终只依赖抽象

最终的效果是这样的：工程只依赖抽象，把两个实现层删掉，引用这两个接口层。

2、配置仓储和服务层的程序集输出

将 Blog.Repository 层和 Service 层项目生成地址改成相对路径，这样大家就不用手动拷贝这两个 dll 了，F6编译的时候就直接生成到了 api 层 bin 下了：

“...\Blog.Core\bin\Debug\”

3、使用 LoadFile 加载服务层的程序集

 var basePath = Microsoft.DotNet.PlatformAbstractions.ApplicationEnvironment.ApplicationBasePath;//获取项目路径
 var servicesDllFile = Path.Combine(basePath, "Blog.Core.Services.dll");//获取注入项目绝对路径
 var assemblysServices = Assembly.LoadFile(servicesDllFile);//直接采用加载文件的方法

这个时候，可能我们编译成功后，页面能正常启动，证明我们已经把 Service 和 Repository 两个服务层的所有服务给注册上了，但是访问某一个接口，还是会出现错误：

这个错误表示，我们的 SqlSugar 服务，没有被注册成功，那肯定就是我们的 Sqlsugar 程序集没有正常的引用，怎么办呢，直接在 api 层引用下就行。

4、解除Service层和Repository层之间的耦合

还记得Blog.Core.Services中的BaseServices.cs么，它还是通过new 实例化的方式在创建，仿照contrller，修改BaseServices并在全部子类的构造函数中注入：

 public class BaseServices<TEntity> : IBaseServices<TEntity> where TEntity : class, new()
    {
        //public IBaseRepository<TEntity> baseDal = new BaseRepository<TEntity>();
        public IBaseRepository<TEntity> baseDal;//通过在子类的构造函数中注入，这里是基类，不用构造函数
  　　　　//...
　　 }


    public class AdvertisementServices : BaseServices<Advertisement>, IAdvertisementServices
    {
        IAdvertisementRepository dal;
        public AdvertisementServices(IAdvertisementRepository dal)
        {
            this.dal = dal;
            base.baseDal = dal;
        }
    }

好啦，现在整个项目已经完成了相互直接解耦的功能，以后就算是Repository和Service如何变化，接口层都不用修改，因为已经完成了注入，第三方Autofac会做实例化的过程。

5、容器内查看注入的服务数据

如果你想看看是否注入到容器里成功了，可以直接看看容器 ApplicationContainer 的内容：

五、 无接口项目注入

1、接口形式的注入

上边我们讨论了很多，但是都是接口框架的，

比如：Service.dll 和与之对应的 IService.dll，Repository.dll和与之对应的 IRepository.dll，

这样，我们在多层之间使用服务的话，直接将我们需要使用的 new 对象，注入到容器里，然后我们就可以使用相应的接口了，

比如：我们想在 controller 里使用AdvertisementServices 类，那我们就可以直接使用它的接口 IAdvertisementServices，这样就很好的达到了解耦的目的，这样我们就可以在API层，就轻松的把 Service.dll 给解耦了；

如果我们需要在 Service类里，使用 AdvertisementRepository ，我们就直接使用对应的接口 IAdvertisementRepository，这样，我们就从 Service 层中，把仓储层给解耦了。

2、如果没有接口

案例是这样的：

如果我们的项目是这样的，没有接口，会怎么办：

// 服务层类
   public class StudentService
    {
        StudentRepository _studentRepository;
        public StudentService(StudentRepository studentRepository)
        {
            _studentRepository = studentRepository;
        }


        public string Hello()
        {
            return _studentRepository.Hello();
        }

    }


    // 仓储层类
     public class StudentRepository
    {
        public StudentRepository()
        {

        }

        public string Hello()
        {
            return "hello world!!!";
        }

    }


    // controller 接口调用
    StudentService _studentService;

    public ValuesController(StudentService studentService)
    {
        _studentService = studentService;
    }

这样的话，我们就不能使用上边的接口注入模式了，因为我们上边是把注入的服务，对应注册给了接口了 .AsImplementedInterfaces() ，我们就无法实现解耦了，因为根本没有了接口层，所以我们只能引用实现类层，这样注入：

通过 builder.RegisterAssemblyTypes(assemblysRepository); 方法直接注入服务，没有其他的东西。

3、如果是没有接口的单独实体类

public class Love
    {
        // 一定要是虚方法
        public virtual string SayLoveU()
        {
            return "I ♥ U";
        }

    }

//---------------------------

////只能注入该类中的虚方法
builder.RegisterAssemblyTypes(Assembly.GetAssembly(typeof(Love)))
    .EnableClassInterceptors()
    .InterceptedBy(typeof(BlogLogAOP));

六、同一接口多实现类注入

这里暂时没有实例代码，如果你正好需要，可以看看这个博友的栗子：https://www.cnblogs.com/fuyujian/p/4115474.html

我会在之后的时间写个栗子放到这里。

七、CODE

https://github.com/anjoy8/Blog.Core

https://gitee.com/laozhangIsPhi/Blog.Core