标签：
Spring -- IOC/DI 基础概念
思维导图：
-------------------------------------------------------
IoC/DI 的基本概念
IoC是什么 ?
IoC -- Inversion of control, 控制反转
在Java开发中，IoC意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式，是一种减少类与类之间依赖的设计原则.
理解IoC的关键是明确"谁控制谁，控制什么，为何是反转，哪些方面反转了"，下面来深入分析一下：
谁控制谁，控制了什么： 传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建以来对象; 而IoC是有专门的一个容器来创建这些对象,即由IoC容器来控制对象的创建; 控制什么 ---> 主要控制了外部资源的获取
为何是反转,哪些方面反转了: 有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转; 而反转则是由容器来帮忙创建及注入依赖对象; 为何是反转? ---> 因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转; 哪些方面反转了？ ---> 依赖对象的获取被反转了.
传统程序设计，都是主动去创建相关对象然后再组合起来,下面用图说明一下:
当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如下图：
IoC能干什么?
IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试; 有了IoC容器后, 把创建对象和查找依赖对象的控制权交给了容器, 由容器进行注入组合对象, 所以对象与对象之间是松散耦合, 这样也方便测试, 利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活.
其实，IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了"主从换位"的变化,应用程序原本是老大,要获取什么资源都是主动出击,但是在IoC/DI思想中，应用程序就变成被动的了,被动的等待IoC容器来创建并注入它所需要的资源了.
DI是什么?
DI -- Dependency Injection,依赖注入
即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中. 依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不用关心具体的资源来自何处、由谁实现.
理解DI的关键是 "谁依赖谁,为什么需要依赖, 谁注入谁，注入了什么"，下面来深入分析一下：
谁依赖于谁 : 应用程序依赖于IoC/DI容器
为什么需要依赖 : 因为反转后，应用程序所依赖都资源都在IoC/DI容器中
谁注入谁 : IoC/DI容器注入应用程序
注入了什么: 注入了应用程序需要的外部资源，比如：依赖关系
控制反转和依赖注入之间是同一个概念吗?
它们不是同一个概念，但是它们是同一个概念的不同角度的描述。
控制反转（IoC）从 IoC容器的角度来说
依赖注入（DI） 从应用程序的角度来说
何为外部资源?
对于一个类来说，所谓外部资源，就是指在自己类的内部不能得到或实现的东西。
比如，在类里面要读取一个配置文件，那么，这个配置文件就相当于这个类的外部资源
比如，A类里面要调用B类，那么对于A类来说B类就是外部资源
-------------------------------------------------------------------
IoC/DI基本的思想演变
（1）Java基础阶段
在C类里面需要使用接口A，最原始的写法是：
A a = new A1(); 或者 A a = new A2(); 然后通过a来调用接口的方法，对于C来说是主动实例化对象，直接获取依赖.
上面这种实现方法的缺点：
a、更换实现需要重新编译源代码
b、很难更换实现，很难测试
c、耦合实例生产者和实例消费者
（2）Factory阶段
使用工厂模式 -- Factory,在C类里面需要使用接口A，应用工厂模式的写法是：
A a = Factory.createA(); 然后通过a来调用接口的方法，这样的话对于C来说是被动实例化对象，间接获取依赖，但对于工厂类来说是主动实例化对象、获取依赖
上述实现方式有何缺点：
1、只是将阶段1中 实例化对象、获取依赖 放入到了工厂中，但是主动的问题还是存在
2、更换实现需要重新编译源代码
3、很难更换实现、难于测试
（3）Factory+xml+反射 阶段
继续进化到使用工厂模式加配置文件 --- Factory + xml +反射
在C类里面需要使用接口A，应用工厂模式的写法是：
A a = Factory.createA(); 然后通过a来调用接口的方法。在工厂类里面使用配置文件来决定要实例化的具体类。对于C类说是被动创建对象，间接获取依赖，对于工厂来说也是被动的。
上述实现方式的缺点：
1、如何实例化带参数的类
2、如何在对调用方法的传递值
（4）IoC/DI阶段
继续进化，就到了IoC/DI的层次了，在这种设计里面，出现了IoC/DI容器，容器对IoC/DI涉及的元素进行整体控制，并提供更多更好的通用服务。
此时在C类里面需要使用接口A，以Sprin为列：
A a = BeanFactory.getBean("XXX"); 然后通过a来调用接口的方法
此时由IoC/DI容器来创建对象和装配对象，并管理对象生命周期。对于应用程序而言，就是被动实例化和被动接受依赖了。
-------------------------------------------------------------------
IoC/DI容器的概念和Bean的概念
Ioc/DI的基本思想：
1、把程序之间的依赖关系去掉
2、把程序对象设置到IoC/DI容器的配置中，作为Bean来统一管理
3、由IoC/DI容器来管理Bean的创建、实例化
4、由IoC/DI容器来把Bean之间的关系注入到需要这些关系的对象里面
简而言之：就是把对象之间的依赖关系全部去掉，由IoC/DI容器来管理对象和对象之间的依赖关系，实现对象之间的松散耦合.
IoC容器： 简单的理解就是，实现IoC思想，并提供对象创建、对象装配以及对象生命周期管理的软件就是IoC容器
IoC理解：
1、应用程序无需主动new对象;而是描述对象应该如何被创建即可，IoC容器帮你创建，即被动实例化;
2、应用程序不需要主动装配对象之间的依赖关系，而是描述需要哪个服务，IoC容器会帮你装配，被动接受装配;
3、主动变被动，以前创建对象、装配对象的依赖关系都是由应用程序主动完成，现在变成被动了由IoC容器来完成;
4、应用程序不知道依赖的具体实现，只知道需要提供某类服务的对象,达到并松散耦合;
5、是一种让服务消费者不直接依赖于服务提供者的组件设计方式，是一种减少类与类之间依赖的设计原则.
使用Ioc/DI容器开发需要改变思路：
1、应用程序不主动创建对象，但是要描述创建它们的方法
2、在应用程序代码中不直接进行服务的装配，但是要描述哪一个组件需要哪一项服务，由容器负责将这些装配在一起
也就是说：所有的组件都是被动的，组件初始化和装配都由容器负责，应用程序只是获取相应的组件后，实现应用的功能即可.
(PS： IoC/DI是思想，不是纯实现技术。IoC是框架共性，只是控制权的转移到了框架，所以不能因为实现了IoC就叫IoC容器，而一般除了实现了IoC外，还具有DI功能的才叫IoC容器，因为容器除了要负责创建并装配组件关系，还需要管理组件的生命周期)
--------------------------------------------------------------------------
（PS： 我不生产东西，本文所有内容都是从网上收集、整理、思考后的一个总结）
标签：
原文地址：http://www.cnblogs.com/xinhuaxuan/p/5500179.html
