讲IOC之前，我们要先说说曾经当做引子：在还没有Spring之前，项目的创建是怎样的。
Dao层操作：
- 创建User接口
- 声明其接口实现类（UserDaoImpl）
Service层操作：
- 创建UserService接口
- 声明其实现类（UserServiceImpl）
这样如今可称之为“原始”的业务，当然可以解决业务所需。而带来的问题同样是明显的：用户的需求可能会影响我们已编写好的代码，因此就需要根据用户的需求去修改源代码。一次两次没什么，三次四次…也能忍。
可成百上千次呢？代码量如果十分巨大呢？那修改的成本真的就值得掂量掂量了。作为最有投机精神的程序员，自然不会允许这样繁杂的工作去占用自己本就珍贵的摸鱼时间。
因此，Set注入应运而生：
之前，程序主动创建对象，主动权掌握在程序员手上，交互过程如图：
而使用Set注入后，程序由主动创建对象变为了被动接受对象。不再具有主动性，事情就变得完全不一样了：
这样的思想无疑是革命性的，举一个不太恰当的例子：就相当于让系统从客户端摇身一变，成了服务器。它从本质上解决了问题，程序员终于不用再去管理对象的创建了，系统的耦合度大大降低，它可专注于业务的实现。
Set注入，相当于IOC的原型。引子讲完了，开始侃正文。
在真正了解IOC之前，还要对两个名词有概念：
-
IOC（控制反转）是一种抽象的设计思想
-
DI（依赖注入）实现IOC的一种方法
当然，也有人认为DI不过是IOC的另一种说法，但是抽象的思想≠具体的实现方法。更何况如果在不使用IOC的系统中使用面向对象编程，对象的创建与对象间的依赖关系完全硬编码在程序中，通俗的讲就是“写死”了。对象的创建由程序自身控制。
而使用IOC后，对象的创建交给了第三方，所谓“控制反转”无非是：获得依赖对象的方式反转。
Spring框架使得调用者只需要被动地接收Spring为调用者的成员赋值即可，不需要主动获取被依赖对象。这种被动获取方式就叫做“依赖注入”。当然，也应用了IOC（控制反转）思想。
IOC是Spring框架的核心内容，可以有多种方法完美的实现IOC，比如利用注解或XML配置。（新版本Spring可支持零配置实现IOC）
总结一下上面写的晦涩难懂的话便是：
控制反转是一种通过描述（XML或注解）并通过第三方去生产或产生特定对象的方式，在Spring中实现控制反转的是IOC容器，其实现方法是依赖注入。（Dependency Injection 简称 DI）
IOC的实现同样也需要一个过程：
Spring容器在初始化时先读取配置文件，根据配置文件或元数据创建与组织对象存入容器中，程序使用时再从IOC容器中取出需要的对象。
采用XML方式配置Bean的时候，Bean的定义信息是和实现分离的，而采用注解的方式可以把两者合为一体，Bean的定义信息直接以注解的形式定义在实现类中，从而达到了零配置的目的。
实现完成后，彻底不用在程序中改动了，要实现不同的操作。
只需要在XML配置文件中进行修改。
所谓IOC，便是：对象由Spring来创建，管理，装配。
