昨天对spring有了一个整体的认识，在spring核心架构体系五个组成部分中，核心容器是spring的一个重要部分，而核心容器的工作原理或者说思想是IOC（控制反转）DI（依赖注入）。
Spring的Ioc[Inverse of Controller]机制
控制反转[Ioc]：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控。
控制反转是一种思想，其具体实现就是依赖注入！
依赖注入[DI:Dependency Injection]：组件之间的依赖关系由容器在运行期决定，由容器动态的将某种依赖关系注入到组件之中。
今天 就来学习一下什么是IOC和DI
一、什么是控制反转：
（1）IoC 不是一种技术，只是一种思想：
传统的编程思想是应用程序在运行的过程中可能会需要其他类的对象，这时候应用程序会先创建需要的类对象，也就是说应用程序在运行时需要啥，自己动手通过new创建出对象，主动权在应用程序。
而控制反转就是让应用程序将控制权交出来，Spring所倡导的开发方式就是：所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。
理解好Ioc的关键是要明确“谁控制谁，控制什么，何为反转（有反转就应该有正转了），如何反转了”，那我们来深入分析一下：
●谁控制谁，控制什么：刚才说过传统的Java EE程序是在程序运行的时候程序自己通过new来创建需要的对象，而spring则是通过容器来创建对象，所以说是IOC容器控制对象的创建。
●何为反转，如何反转了：反转其实是程序交出控制权，本来对象的创建是程序自己完成的，而现在是IOC在程序需要的时候创建对象并注入程序中，这就是控制权的反转。运行程序由主动创建变被动接受需要的对象的过程就是反转的过程。
二、为什么要反转控制-----用它有什么好处
先来看一下不使用反转控制的开发模式（此处借用大神的分析思路）
传统的应用开发就像这些齿轮，他们之间的耦合度很高，每一个模块都需要依赖于其他模块，想想其中如果某个模块出现了问题，是不整个系统就崩溃了，不能运行了；而且在开发的过程中整个系统的各个模块要一起开发，因为在开发B模块的时候可能需要A模块，如果想在之后添加新的功能需要改动的工作量可能会很大，这些都给开发带来了很大的不方便。
而反转控制：各模块之间出现了第三者来协调他们之间的关系，也就是各模块不用直接接触了，你需要什么Ioc容器给你创建。此时一个模块出现问题了其他模块依旧是正常的，维护起来也很方便。这种方式降低了模块间的耦合度，同时比如说B模块如果在其他系统也是用，那就可以直接将B模块移接过去，这不提高代码的重用了吗。
通过这些内容应该对控制反转有了认识。
三、依赖注入（DI）
在文章的开头说过：控制反转是一种思想，其具体实现就是依赖注入！
刚才已经说了控制反转了，那控制反转是怎么实现的呢？
就是通过依赖注入实现的。其实控制反转与依赖注入不就是一件事的不同说法吗？
理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：
●谁依赖于谁：当然是应用程序依赖于IoC容器；
●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
很显然有了IOC应用程序成了衣来伸手饭来张口的大少爷，什么都不用干了，就是活着，当然或者需要依赖外界的资源，饿了爸妈喂，没钱了爸妈给；爸妈喂、给的过程不就是注入吗？
写到这我们应该对控制反转和依赖注入有了清楚的认识。
总结：
我们可以把IOC容器的工作模式看做是工厂模式的升华，可以把IOC容器看作是一个工厂，这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言的的反射编程，根据配置文件中给出的类名生成相应的对象。从实现来看，IOC是把以前在工厂方法里写死的对象生成代码，改变为由配置文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。
参考资料：