一、浅谈IOC
IOC（Inversion of Control，控制反转）是spring的核心，贯穿始终。所谓IOC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系：
传统开发模式：对象之间互相依赖 耦合性太高，一旦系统复杂，要修改其中一个模块就有可能牵一发而动全身， 维护成本高。
IOC开发模式：IOC容器安排对象之间的依赖
二、IOC理论的背景
由图3可知，对象之间的耦合已经降到最低关系。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中，很多的J2EE项目均采用了IOC框架产品spring。IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦，如图2、3所示。
三、依赖注入（DI）
IOC的另外的名字叫做依赖注入（Dependency Injection），所谓的依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。所以，依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。
就像上图一样：从外部usb读取文件，主机没必要知道通过啥设备，只要符合连接接口就可以了，外部设备主动权由我们自己控制，这样就解耦到最低。
四、IOC的好处
IOC在编程过程中不会对业务对象构成很强的侵入性，使用IOC之后，对象具有更好的可实行性，可重用性和可扩展性：
4.1 降低组件之间的耦合度
这样在开发过程中，我只需要关心自己开发的class有没有问题。代码中的每一个Class都可以单独测试，彼此之间互不影响，只要保证自身的功能无误即可，这就是组件之间低耦合或者无耦合带来的好处。
4.2 提高开发效率和产品质量
在一个大中型项目中，团队成员分工明确、责任明晰，很容易将一个大的任务划分为细小的任务，开发效率和产品质量必将得到大幅度的提高。
4.3 统一标准，提高模块的复用性
4.4 模块具有热插拔特性
五、IOC的通俗理解
IOC通俗的理解如下：
IOC控制反转：说的是创建对象实例的控制权从代码控制剥离到IOC容器控制，实际就是你在xml文件控制，侧重于原理
DI依赖注入：说的是创建对象实例时，为这个对象注入属性值或其它对象实例，侧重于实现
六、使用中注意事项：
使用IOC框架产品能够给我们的开发过程带来很大的好处，但是也要充分认识引入IOC框架的缺点，做到心中有数，杜绝滥用框架。
第一、软件系统中由于引入了第三方IOC容器，生成对象的步骤变得有些复杂，本来是两者之间的事情，又凭空多出一道手续，所以，我们在刚开始使用IOC框架的时候，会感觉系统变得不太直观。所以，引入了一个全新的框架，就会增加团队成员学习和认识的培训成本，并且在以后的运行维护中，还得让新加入者具备同样的知识体系。
第二、由于IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。如果你要追求运行效率的话，就必须对此进行权衡。
第三、具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。
第四、IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险
我们大体可以得出这样的结论：一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品，象WEB2.0网站就是这种情况。
更多可参考：http://blog.csdn.net/m13666368773/article/details/7802126