本篇文章主要简单回顾一下IOC容器的概念与其应用场景，主要参考了《Spring 技术内幕——深入解析Spring架构与设计原理》，作为学习过程的一个记录。
1 IoC容器和依赖反转模式
首先简单回顾一下依赖反转的相关概念。如果合作对象的引用或依赖关系的管理由具体的对象来完成，那么会导致代码的高度耦合和可测试性的降低，对于复杂的面向对象系统的设计时极为不利的。在面向对象系统中，对象的依赖关系常常体现在对数据和方法的依赖上，如果把对象的依赖注入交给框架或IoC容器来完成，它可以在解耦的同时提高代码的可测试性，带来的好处是非常可观的。
依赖控制反转的实现有很多中方式。在Spring中，IoC容器是实现这个模式的载体，它可以在对象生成或初始化时直接将数据注入到对象中，也可以通过将对象引用注入到对象数据域的方式来注入对方法调用的依赖。它把对象的依赖关系有序地建立起来，简化了对象依赖关系的管理，在很大程度上简化了面向对象系统的复杂性。
如何反转对以来的控制，把控制权从具体业务对象中转移到平台或框架中，是降低面向对象系统设计和提高面向对象系统可测试性的一个有效解决方案，同时促进了IoC设计模式的发展，是IoC容器要解决的核心问题。
| 注意：应用控制反转后，当对象被创建时，有一个调控系统（这里可以认为成IoC容器）内的所有对象的外界实体将其所依赖的对象的引用传递给它，即依赖注入到对象中。所以控制反转是关于一个对象如何获取它所以来的对象的引用，反转是指责任的反转。 |
通过使用IoC容器，对象依赖关系的管理被反转了，对象之间的相互依赖关系由IoC容器进行管理，并由IoC完成对象的注入。简单地说，很多对象依赖关系的建立和维护并不需要和系统运行状态有很强的关联性，所以可以把在面向对象编程中需要执行的注入新建对象、为对象引用赋值等操作交由容器统一完成。那么这些功能相同的部分就集中称为容器的一部分，成为面向对象系统额基础设施的一部分。
如果对面向对象系统中的对象进行简单分类，可以发现除了一部分为数据对象以外，其余很大一部分都是用来处理数据的。这些对象并不经常变化，且不经常涉及数据和状态共享问题，所以这些对象在系统中以单件的形式起作用就可以满足应用的需求。同时，这些对象讲的依赖关系是相对稳定的，不会随着运行而改变。这些特性使得这些对象非常适合有IoC来管理。
2 Spring IoC的应用场景
首先，可以了解一下Spring和EJB在设计上有何不同。
在Spring中，Spring IoC提供到了一个基本的JavaBean容器，通过IoC模式管理依赖关系，并通过依赖注入和AOP切面增强了为JavaBean这样的POJO对象赋予事务管理、生命周期管理等基本功能。
对于EJB而言，一个简单的EJB组件需要编写远程/本地接口、Home接口以及Bean的实现类，而且EJB运行是依赖与EJB容器的，查找其他EJB组件也需要通过诸如JNDI这样的方式，从而造成了对EJB容器和技术规范的依赖。
在应用开发中，往往需要引用和调用其他组件服务，这种依赖关系如果固化在组件设计中，会造成依赖关系的僵化和维护难度的增加。使用IoC容器，把资源获取的方向反正，让IoC容器主动管理这些依赖，就会是这些依赖关系的适配和管理更加灵活。
本文属于IoC容器容器实现的第一篇，后续会继续深入详细的从源码方面分析它是如何实现的。