依赖注入、控制反转、DI容器、Autofac

依赖注入、控制反转、DI容器

1. 当一个类需要另一个类协作来完成工作的时候就产生了依赖
2. _lxxService = new xxService() 这叫正转
3. public xxController(IxxService xxService)
   { _xxService = xxService; } 这叫反转
   大师说把实现交出去，我只在构造函数负责拿过来，此时优势就体现出来了，这种方式对于代码来讲更加松耦合、可测试和可维护
4. 依赖太多啦，管理不过来了，所以有了DI容器(这个是ASP.NET Core的大杀招)
5. 依赖注入是我为了实现功能用到的一种方法
6. 控制反转是一种思想【引用别人的一句：A依赖于B，并且A掌控B的创建销毁，此时A控制了B，即为“正转”。
   当B的创建销毁在A之外完成，B脱离了A的控制，称之为控制反转（IoC：Invertion of Control）】
7. ASP.NET Core DI容器是在ASP.NET Core MVC程序启动时分配了线程池，绑定服务与实例并且管理着实例的创建与销毁

细说一下DI容器为什么是大杀招：

1. 颠覆了传统的.NET Framework正转思想，
2. 完全是接口设计模式可轻易实现功能的热插拔，分层设计，分布式系统设计
3. 它是轻量级的

组成：

• IServiceCollection 负责注册
• IServiceProvider 负责提供实例

代码例子：

• 随便写个接口和实现类
• Program.cs注册(可以选择不同注册的方式，有着不同的声明周期，具体看图的注释)
  
• 注入
  
• 就能使用接口的实现的方法了

总结一下：
DI容器在Web启用时已经分配了一个空间(简单理解它是线程池和实例)。程序的标准服务(服务本质也是接口)和自己自定义接口都装在里面了。
无法理解DI容器和依赖注入的话，那就无法理解ASP.NET Core MVC的代码，该知识点能帮助我们读懂ASP.NET Core MVC项目50%代码，因为几乎所有ASP.NET Core MVC代码都绕不开DI容器，另外50%是什么呢，大部分是复杂的特征，过滤器，拦截器，约定的视图等等，依然需要专门学习才能掌握

Autofac

此时引出第二个问题，我每个接口注册是不是都要在Program.cs写一句，接口太多的话，Program.cs是不是会很大和很混乱？那么此时就需要用到Autofac，它能实现批量接口注册，还能分多个文件，对于注册管理有非常大规范作用
网上对于Autofac作用描述得其实太过于详细了，其实不需要全部了解，我们只关心它能帮助我们管理DI容器的注册即可
用了Autofac就不要用上面那种最基础的注册模式了，因为使用 Autofac 这样的 IoC 容器来管理依赖已经成为一种标准实践
下面是代码例子

• Nuget安装相关包：Autofac ，Autofac.Extensions.DependencyInjection

• Program.cs使用Autofac
  - Autofac代码
  

• 构造函数注入使用即可