前言
前两节针对.NetCore自带的依赖注入进行简要概述，对于日常开发的需求应该是能满足了，那为什么还需要引入第三方依赖注入组件呢，这里就从自带的依赖注入来分析，有什么样的需求满足不了？主要归纳为以下几点：
-
属性注入：自带的依赖注入不支持属性注入方式，而现阶段开发，属性开发模式应该在程序中无处不在了；
-
按名称注入：自带的依赖注入不支持名称注入，当注入多个同接口的不同实现时，要获取指定类型的对象不太方便，但通过名称可以方便获取；
-
注册方式：自带的依赖注入需要指定具体类型，这样每增加一个新类型就要添加注册，程序员“精益求精”的思维会问：有没有只要添加新类型就能自动注册的方式？有，第三方依赖注入组件提供了程序集注入的形式；
-
其他扩展功能：除了上面提到，第三方依赖注入组件还有很多扩展功能，比如更多的注册方式、子容器管理、基于动态代理的AOP等，这里的AOP很有用，就是通常说的面向切面编程，接下来会对此做一个简单的案例；
说了这么多，不就是为了说明根据实际需要，可以引入第三方依赖注入组件进行增强容器的能力，不废话，直接看看怎么用；
正文
不行，这里还得唠叨一下，毕竟现在开发社区中依赖注入的框架很多，目前都有哪些？又怎么选呢？
比较流行依赖注入组件有哪些呢？
-
Autofac
-
Castle Windsor
-
Unity
-
Spring.Net
-
StructureMap
-
Ninject
这里就不进行性能对比了，有好多大牛进行了性能测试对比，搜索引擎都有，上面看到标注红色的前几个，其实也就是相对来说比较流行，而Spring.Net最近几年用的不火了，不过刚开始的时候的确风靡过一段时间；从开发社区来看，当下Autofac、Castle Windsor是最火，其中Autofac似乎更让开发者喜爱；而对于StructureMap，有大牛做过性能测试，它的性能和Autofac相对其他来说更有优势；
其实我想说，主要是看项目需求啦，如果没有太苛刻的要求的话，可以根据项目技术情况进行选择，但是我还是优先推荐Autofac、Castle Windsor、Unity，强烈推荐Autofac，毕竟大家都在用，好多比较火的框架都集成了，比如：ABP_vNext，不过多会用几个绝对没坏处；
来，开干，将Autofac集成在Asp.NetCore中，三小步搞定：
-
通过Nuget安装Autofac包；
-
修改 Program.cs 将默认ServiceProviderFactory指定为AutofacServiceProviderFactory；
-
在 Startup.cs 中添加 ConfigureContainer 方法 ；
这里加一个模拟业务逻辑层和数据层，后续方便演示
数据层：
业务逻辑层，这一层引用数据层：
ConfigureContainer 方法添加注册
通过以上三步就集成了AutoFac，成不成功拉出来遛遛，在Action中使用：
运行调试，走你：
可见默认属性注入没有开启，注册时优化一下：
再运行调试，走你：
这次运行的时候，服务层属性注入成功，但Controller那还不行，因为我们没有将Contoller的属性注入功能开启，接下下来在程序集注册的时候说说；
通过上面的服务注册，每添加一个类型都要在注册的地方添加，可以通过程序集的注册方式，后续就不用每次添加了，如下：
代码简单说明及注意：
-
代码中的AsImplementedInterfaces是暴露所有接口；
-
Assembly.Load加载程序集，有多种加载方式如Assembly.LoadFrom/LoadFile等，需要注意每个方法的使用前提，不然找不到程序集文件；
-
注册时其中的Where是用来过滤类型，找到符合条件的类型；
运行调试，都注入上了，以后在对应程序集中添加类型就不用每次在注册的地方添加该类型的注册代码了
刚才遗留的控制器属性注入问题，为什么放在这里说呢，因为要用到程序注册方式，两步走：
这样就可以在Controller中进行属性注入了；运行，之前不能注入的都成功了；当然还有其他的方式，这里没有深入；
Autofac的注册方式有点多，这里就不一一举例了，可以到官网进行详情了解； 之前说到AOP功能，这里举例说明一下，毕竟这在实际开发项目中比较重要，这里不说原理，之前写过一篇博客，可以去看一下：
通常，在项目中，业务层做逻辑处理、数据处理比较多，通常我们会在业务层进行相关缓存处理及其他处理，所以这里在业务层中举例演示(当然其他层也可以)：
既然要进行切面处理，得有个地方处理，所以得增加个拦截器，Nuget先安装一个包：Autofac.Extras.DynamicProxy;
注册的时候开启切面功能，并指定对应拦截器进行处理；
这样就能通过拦截器扩展相关功能，业务逻辑前后都行，也可以不调用原有的业务代码，通过拦截器短路，运行结果如下：
可以看到，请求完之后，在对应的业务处理前后都进行了对应处理，这里之所以有两次，那是因为上面测试代码调用了两次；
像这种无嵌入型进行扩展的AOP编程方式，是非常有用的，扩展和维护功能也比较方便，有人说性能问题有降低，当然会有那么一点，相对来说，是可以接受的，除非是扩展业务逻辑耗时多，这就需要另想方案了；
总结
Autofac这里就简要说这么多，详情到官方研究吧，还有很多东西，但思路基本上就是这样；接下来开始说说配置，因为配置比较重要，从之前启动流程中就体现出来；