Spring ioc详解

Spring是一个开源框架，主要实现两件事，IOC（控制反转）和AOP（面向切面编程）。

IOC

 我们都知道，在采用面向对象方法设计的软件系统中，它的底层实现都是由Ñ个对象组成的，所有的对象通过彼此的合作，最终实现系统的业务逻辑。

                 

 

            如果我们打开机械式手表的后盖，就会看到与上面类似的情形，各个齿轮分别带动时针，分针和秒针顺时针旋转，从而在表盘上产生正确的时间。图1中描述的就是这样的一个齿轮组，它拥有多个独立的齿轮，这些齿轮相互啮合在一起，协同工作，共同完成某项任务。我们可以看到，在这样的齿轮组中，如果有一个齿轮出了问题，就可能会影响到整个齿轮组的正常运转。

        齿轮组中齿轮之间的啮合关系，与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。现在，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。

                        

 

         耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间，模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中，很多的J2EE项目均采用了国际奥委会框架产品春季。

2.什么是控制反转（IoC）
        IOC是Inversion of Control的缩写，多数书籍翻译成“控制反转”，还有些书籍翻译成为“控制反向”或者“控制倒置”。
        1996年，Michael Mattson在一篇有关探讨面向对象框架的文章中，首先提出了IOC这个概念。对于面向对象设计及编程的基本思想，前面我们已经讲了很多了，不再赘述，简单来说就是把复杂系统分解成相互作用合作的对象，这些对象类通过封装以后，内部实现对外部是透明的，从而降低了解决问题的复杂度，而且可以灵活地被重用和扩展.IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的，如下图：

 

                      

 

        大家看到了吧，由于引进了中间位置的“第三方”，也就是IOC容器，使得A，B，C，d这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方” IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。

 

                    我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：

 

                            

 

       我们现在看到的画面，就是我们要实现整个系统所需要完成的全部内容。这时候，A，B，C，d这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现阿的时候，根本无须再去考虑B，C和d了，对象之间的依赖关系已经降低到了最低程度。所以，如果真能实现IOC容器，对于系统开发而言，这将是一件多么美好的事情，参与开发的每一成员只要实现自己的类就可以了，跟别人没有任何关系！

我们再来看看，控制反转（IOC）到底为什么要起这么个名字我们来对比一下？

软件系统在没有引入IOC容器之前，如图1所示，对象甲依赖于对象B，那么对象阿在初始化或者运行到某一点的时候，自己必须主动去创建对象乙或者使用已经创建的对象B.无论是创建还是使用对象B，控制权都在自己手上。
软件系统在引入IOC容器之后，这种情形就完全改变了，如图3所示，由于IOC容器的加入，对象甲与对象乙之间失去了直接联系，所以，当对象甲运行到需要对象乙的时候，IOC容器会主动创建一个对象乙注入到对象甲需要的地方。

        通过前后的对比，我们不难看出来：对象甲获得依赖对象乙的过程，由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。

3. IOC的别名：依赖注入（DI）
        2004年，Martin Fowler探讨了同一个问题，既然IOC是控制反转，那么到底是“哪些方面的控制被反转了呢？”，经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”控制被反转之后，获得依赖对象的过程由自身管理IOC容器主动注入于是，他给“控制反转“取了一个更合适的名字叫做”依赖注入（Dependency Injection）“。他的这个答案，实际上给出了实现IOC的方法：注入。所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。

        所以，依赖注入（DI）和控制反转（IOC）是从不同的角度的描述的同一件事情，指就是通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。

6.  IOC容器的一些产品

Sun ONE技术体系下的IOC容器有：轻量级的有Spring、Guice、Pico Container、Avalon、HiveMind；重量级的有EJB；不轻不重的有JBoss，Jdon等等。Spring框架作为Java开发中SSH(Struts、Spring、Hibernate)三剑客之一，大中小项目中都有使用，非常成熟，应用广泛，EJB在关键性的工业级项目中也被使用，比如某些电信业务。
.Net技术体系下的IOC容器有：Spring.Net、Castle等等。Spring.Net是从Java的Spring移植过来的IOC容器，Castle的IOC容器就是Windsor部分。它们均是轻量级的框架，比较成熟，其中Spring.Net已经被逐渐应用于各种项目中。

依赖注入的三种方式：（1）接口注入（2）Construct注入（3）Setter注入

控制反转（IoC）与依赖注入（DI）是同一个概念，引入IOC的目的：（1）脱开、降低类之间的耦合；（2）倡导面向接口编程、实施依赖倒换原则； （3）提高系统可插入、可测试、可修改等特性。

Ioc和DI的区别：

（1）Ioc：控制反转，把创建对象交给Spring进行配置

（2）DI：依赖注入，向类里面的属性中设置值

（3）二者关系：DI不能单独存在，要在Ioc基础之上来完成操作，即要先创建对象才能注入属性值。

　　DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

　　理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：

　　●谁依赖于谁：当然是应用程序依赖于IoC容器；

　　●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

　　●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

　　●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

　　IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

7. 使用IOC框架应该注意什么

使用IOC框架产品能够给我们的开发过程带来很大的好处，但是也要充分认识引入IOC框架的缺点，做到心中有数，杜绝滥用框架。
第一、软件系统中由于引入了第三方IOC容器，生成对象的步骤变得有些复杂，本来是两者之间的事情，又凭空多出一道手续，所以，我们在刚开始使用IOC框架的时候，会感觉系统变得不太直观。所以，引入了一个全新的框架，就会增加团队成员学习和认识的培训成本，并且在以后的运行维护中，还得让新加入者具备同样的知识体系。
第二、由于IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。如果你要追求运行效率的话，就必须对此进行权衡。
第三、具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。
第四、IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险。
我们大体可以得出这样的结论：一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品，象WEB2.0网站就是这种情况。

 

　用图例说明一下，传统程序设计如图2-1，都是主动去创建相关对象然后再组合起来：

图1-1 传统应用程序示意图

　　当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图2-2所示:

图1-2有IoC/DI容器后程序结构示意图

 

简单案例

控制反转，也可以称为依赖倒置。

所谓依赖，从程序的角度看，就是比如A要调用B的方法，那么A就依赖于B，反正A要用到B，则A依赖于B。所谓倒置，你必须理解如果不倒置，会怎么着，因为A必须要有B，才可以调用B，如果不倒置，意思就是A主动获取B的实例：Bb=newB()，这就是最简单的获取B实例的方法（当然还有各种设计模式可以帮助你去获得B的实例，比如工厂、Locator等等），然后你就可以调用b对象了。所以，不倒置，意味着A要主动获取B，才能使用B；到了这里，就应该明白了倒置的意思了。倒置就是A要调用B的话，A并不需要主动获取B，而是由其它人自动将B送上门来。

所谓控制反转，就是控制权的转移，举例说明：一个人要开车，正常情况下，人应该自己去找车，而实现控制反转后，人就不需要考虑车从哪里来了，直接开就行了，人就把找车的控制权转移给了别的对象。体会一下下面的代码

先定义一个接口Car

1 2 3

public interface Car {   void go(); }

定义两种车

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Benz implements Car {     public void go() {     System.out.println("benz go......");   } }   public class BMW implements Car{     public void go() {     System.out.println("bmw go......");   } }

下面是人开车

1 2 3 4 5 6 7 8 9

public class Person {     Car car=new Benz();     void DriveCar(){     System.out.println("begin drive");     car.go();   } }

这是正常的代码控制流程，人想要开车，就要自己去实例化一辆车。但是，这样子的话，这个人就只能开一种车。怎么样才能让这个人能开各种车呢，就是要实现控制反转，也就是说，人不再去自己实例化车了，那人怎样得到车的对象呢？我们可以通过依赖注入（Dependency Injection，简称DI）的方式来让人得到车的对象，从而实现控制反转。所以，我们要修改Person类

1 2 3 4 5 6 7 8 9 10 11 12

public class Person {     Car car=null;   public Person(Car car){     this.car=car;   }     void driveCar(){     System.out.println("begin drive");     car.go();   } }

现在的Person类已经不自己实例化车的对象了，而是通过构造函数来获得车的对象，所以，这个类就可以开各种车了，只要这个车实现了Car接口就可以。看一下如何使用Person类

1 2 3 4

public static void main(String[] args) {   Person p=new Person(new Benz());   p.driveCar(); }

现在的Person类可以开不止一种车，只要你通过构造函数传递进来。在这个例子中，Car对象就是Person类的依赖，当我们实例化Person类时，将一个Car的实例传递给Person类，就是依赖注入，我们的Person类从而实现了控制反转。

控制反转到底反转了什么？有种说法是这样的：所谓控制反转，反转的是获取对象依赖的过程。控制权反转后，获取依赖对象的过程由自身管理变为由IOC容器注入。

Spring实现依赖注入的方式

在上面的这行代码中Person p=new Person(new Benz());，我们通过手动的方式new了一个Benz()的对象，然后将其注入到Person类中。而Spring不这么干，因为Spring觉得，你这行代码实例化了一个具体的Benz类，如果你以后想要在这里实例化一个BMW类的话，岂不是要修改代码？那我干脆写到配置文件里好了，即便你将来要该注意，至少不需要修改代码，于是就有了下面的配置

1 2 3 4 5 6

<beans>   <bean id="car" class="com.XXX.Benz" />   <bean id="person" class="com.XXX.Person" >     <property name="car" ref="car" />   <bean/> </beans>

然后，Spring再提供一些机制，从配置文件中获取Person类的对象时，它所以来的car对象会被装配进来，而person对象不需要关心到底是哪个具体的类被传递进来了。所以，Spring作为一个IOC框架主要做了两步：创建对象和组装对象之间的关系。

2.1、IoC(控制反转)

　　首先想说说IoC（Inversion of Control，控制反转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。

　　那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。

2.2、DI(依赖注入)

　　IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了 spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。那么DI是如何实现的呢？ Java 1.3之后一个重要特征是反射（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性，spring就是通过反射来实现注入的。

　　理解了IoC和DI的概念后，一切都将变得简单明了，剩下的工作只是在spring的框架中堆积木而已。

三、我对IoC(控制反转)和DI(依赖注入)的理解

　　在平时的java应用开发中，我们要实现某一个功能或者说是完成某个业务逻辑时至少需要两个或以上的对象来协作完成，在没有使用Spring的时候，每个对象在需要使用他的合作对象时，自己均要使用像new object() 这样的语法来将合作对象创建出来，这个合作对象是由自己主动创建出来的，创建合作对象的主动权在自己手上，自己需要哪个合作对象，就主动去创建，创建合作对象的主动权和创建时机是由自己把控的，而这样就会使得对象间的耦合度高了，A对象需要使用合作对象B来共同完成一件事，A要使用B，那么A就对B产生了依赖，也就是A和B之间存在一种耦合关系，并且是紧密耦合在一起，而使用了Spring之后就不一样了，创建合作对象B的工作是由Spring来做的，Spring创建好B对象，然后存储到一个容器里面，当A对象需要使用B对象时，Spring就从存放对象的那个容器里面取出A要使用的那个B对象，然后交给A对象使用，至于Spring是如何创建那个对象，以及什么时候创建好对象的，A对象不需要关心这些细节问题(你是什么时候生的，怎么生出来的我可不关心，能帮我干活就行)，A得到Spring给我们的对象之后，两个人一起协作完成要完成的工作即可。

　　所以控制反转IoC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，比如转移交给了IoC容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器了，通过IoC容器来建立它们之间的关系。

　　这是我对Spring的IoC(控制反转)的理解。DI(依赖注入)其实就是IOC的另外一种说法，DI是由Martin Fowler 在2004年初的一篇论文中首次提出的。他总结：控制的什么被反转了？就是：获得依赖对象的方式反转了。