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