- A+
1.IOC的理论背景
大家开发理念，一直都是奔着架构稳定、低耦合性。而IOC初衷，就是为了解决模块依赖问题，理解《六大设计原则(SOLID)》
如图所示，在我们开发中，业务的实现，就是靠着模块中的类与类、跨模块的类与类，相互调用与依赖完成的。而这就导致我们改动一个类，就会使得所有用到这个类的地方都要改一遍。比如把My SQL更换成SQL Server，我们不应该影响业务代码，只需要更改数据驱动的实现就行（我相信大家遇见过这种烦人的事情）
而这个时候我们就想，可不可以不由我们自己实例化，而是交给一个专门的工厂帮我们实例化（IOC的前身其实就是工厂）为了解决这个问题，软件专家Michael Mattson提出了IOC理论
2.什么是IOC
IOC(控制反转)是Inversion of Control的缩写，为了解决背景交代的问题
- 控制：首先控制实例的创建，不用我们控制具体创建什么实例，而是交给工厂，类似于第三方的概念，他和我们业务没任何关系，我们面向抽象编程，由它帮我们统一控制实例创建，改变它就所有的统一改变（完美）。
- 反转：其次对象之间依赖不能由我们去创建，我们调用的时候，不用关心被调用的类与其他类之间的依赖关系，也交给第三方去帮我们解决依赖的问题，我们只管调用。（更完美）
思路就如上图所示，但产生了另一个问题，既然调用者不关心，那当前对象所依赖的对象，怎么来，难道凭空产生？于是就有了注入这种模式的概念
3.什么是DI
DI(依赖注入)是Dependency Injection的缩写，所以他们其实是为了解决同一问题。
Martin Fowler(马丁·福勒)，国际著名的OO专家，认为我们需要为该模式指定一个更具体的名称。控制反转是一个过于笼统的术语，因此人们会感到困惑。与IoC倡导者进行了大量讨论之后，决定使用依赖注入这个名称。
依赖项注入有三种主要样式，分别是：构造函数注入、属性注入、接口注入
总结
是不是没我们想的那么复杂繁琐，简单来说：其实就是一种架构思想而引生出来的一个工具。目的就是为了解耦，使架构更稳定。
其他
其他相关具体实现原理和使用方式，我就不详细介绍了，大家可以查找相关资料学习。后面我会通过代码实现一个我们自己的IOC容器，并且嵌入到.NET Core框架，以便于大家对IOC更深层次的理解。大家可以关注我后续更新，由于是空余时间更新，所以更新时间比较慢。
我也给大家贴一下《控制反转容器和依赖注入模式》文章地址：
- 原文章地址：http://martinfowler.com/articles/injection.html
- 中文翻译地址：https://files.cnblogs.com/files/stono/DependencyInjection.pdf
