以简御繁——介绍IOC

1.IOC的理论背景

大家开发理念，一直都是奔着架构稳定、低耦合性。而IOC初衷，就是为了解决模块依赖问题，理解《六大设计原则(SOLID)》

如图所示，在我们开发中，业务的实现，就是靠着模块中的类与类、跨模块的类与类，相互调用与依赖完成的。而这就导致我们改动一个类，就会使得所有用到这个类的地方都要改一遍。比如把My SQL更换成SQL Server，我们不应该影响业务代码，只需要更改数据驱动的实现就行（我相信大家遇见过这种烦人的事情）

而这个时候我们就想，可不可以不由我们自己实例化，而是交给一个专门的工厂帮我们实例化（IOC的前身其实就是工厂）为了解决这个问题，软件专家Michael Mattson提出了IOC理论

2.什么是IOC

IOC(控制反转)是Inversion of Control的缩写，IOC理念就是为了解决背景交代的问题，是一种设计思想，可以认为是一种全新的设计模式，我们具体刨析一下控制反转设计思想：

控制：首先控制实例的创建，不用编程的时候去控制具体创建什么实例，而是交给工厂，他是第三方的概念，他和我们业务没任何关系，我们面向抽象编程，由它帮我们统一控制实例创建，改变它，就所有的统一改变！（完美）
反转：其次对象之间依赖不能由我们去创建，我们调用的时候，不用关心被调用的类与其他类之间的依赖创建，也交给第三方去帮我们解决依赖的问题，我们只管调用。（更完美）

而IOC容器（第三方）就是为了这两个设计理念而诞生的，我们只需要把实例映射关系注册到IOC容器中，实例的创建由容器统一构建，如上图所示。

但产生了另一个问题，既然调用者不关心我的依赖，那我依赖的对象怎么来，难道凭空产生？于是就有了注入这种模式。

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