2.1.1 什么是控制反转IoC（Inversion of Control）？
许多应用都是由两个或多个类通过彼此的合作来实现业务逻辑的，这使得每个对象都需要与其合作对象的引用（即需要依赖别的类），如果这个获取过程都要靠自己实现，那么代码的耦合度就很高，并且难以测试。
举个例子：
软件系统中对象的高耦合现象。全体齿轮的转动由一个对象来控制，软件中的对象就像齿轮一样，协同工作，但是互相耦合，一个零件不能正常工作，整个系统就崩溃了。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形：
控制反转（IoC）就是借助第三方实现具有依赖关系的对象之间解耦。
由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用。
再举一个例子，“我”充当一个入口类，在这个入口类中，我每次吃饭的时候都要买一双一次性筷子（每一次使用都要new一次），在这样的关系下，是“我”（即调用者）每次都要“主动”去买一次性筷子（另一个类），我对筷子说你老老实实的过来我的手上，是我控制了筷子，那好，在这种控制正转的关系下，放在现实生活当中，肯定是不现实的，而且人是懒惰的，他总会去创造出更加方便自己生活的想法，更确切的做法是，买一双普通的筷子（非一次性），把他放在一个容器当中（在Spring中叫做IOC容器），你需要使用的时候就对容器说：IOC我想要用筷子（向容器发出请求），接着筷子就会“注入”到我的手上，而在这个过程当中，你不再是控制方，反而演变成一名请求者（虽然本身还是调用者），依赖于容器给予你资源，控制权坐落到了容器身上，于是这就是人们俗称的控制反转。
2.1.2 Spring IoC的应用场景
在Spring框架流行前，大家更熟悉的是EJB（Enterprise JavaBean）这种开发模式，两者在提供事务管理、生命周期管理等服务上没有太大差别，只是在获取服务的方式上有很大不同：
(1) 在Spring中，Spring IoC提供了一个基本的JavaBean容器，通过IoC模式管理依赖关系，并通过依赖注入和AOP切面增强了为JavaBean这样的POJO对象赋予事务管理、生命周期管理等基本功能；
(2) 而对于EJB，一个简单的EJB组件需要编写远程/本地接口、Home接口以及Bean的实现类，而且EJB运行是不能脱离EJB容器的，查找其他EJB组件也需要通过诸如JNDI这样的方式，从而造成对EJB容器和技术规范的依赖。
也就是说Spring把EJB组件还原成了POJO对象或者JavaBean对象，降低了应用开发对传统J2EE技术规范的依赖。
在具体的注入实现中，接口注入（Type 1 IoC）、setter注入（Type 2 IoC）、构造器注入（Type 3 IoC）是主要的注入方式。在Spring的IoC设计中，setter注入和构造器注入是主要的注入方式；相对而言，使用Spring时setter注入是常见的注入方式，而且为了防止注入异常，Spring IoC容器还提供了对特定依赖的检查。
另一方面，在应用管理依赖关系时，可以通过IoC容器将控制进行反转，在反转的实现中，如果能通过文本来完成配置，并且还能通过工具对这些配置信息进行可视化的管理和浏览，那么肯定是能够提高对组件关系的管理水平，并且如果耦合关系需要变动，并不需要重新修改和编译Java源码，这符合在面向对象设计中的开闭准则，并且能够提高组件系统设计的灵活性。