duffy 2014-08-22 09:32 原文
- 在 Java EE企业应用开发中，前面介绍的IoC（控制反转）设计模式，是解耦组件之间复杂关系的利器，Spring IoC模块就是这个模式的一种实现。
- 在EJB模式中，应用开发人员需要编写EJB组件，而这种组件需要满足EJB容器的规范，才能运行在EJB容器中，从而获取事务管理、生命周期管理这些组件开发的基本服务。
- 从获取的基本服务上看，Spring提供服务和EJB容器提供的服务并没有太大的差别，只是在具体怎样获取服务的方式上，两者的设计有很大的不同：在Spring中，Spring IoC提供了一个基本的JavaBean容器，通过IoC模式管理依赖关系，并通过依赖注入和AOP切面增强了为JavaBean这样的POJO对象赋予事务管理、生命周期管理等基本功能；而对于EJB，一个简单的EJB组件需要编写远程/本地接口、Home接口以及Bean的实现类，而且EJB运行是不能脱离EJB容器的，查找其他EJB组件也需要通过诸如JNDI这样的方式，从而造成对EJB容器和技术规范的依赖。也就是说Spring把EJB组件还原成了POJO对象或者JavaBean对象，降低了应用开发对传统J2EE技术规范的依赖。
- 同时，在应用开发中，以应用开发人员的身份设计组件时，往往需要引用和调用其它组件的服务，这种依赖关系如果固化在组件设计中，就会造成依赖关系的僵化和维护难度的增加，这个时候，如果使用IoC容器，把资源获取的方向反转，让IoC容器主动管理这些依赖关系，将这些依赖关系注入到组件中，那么会让这些依赖关系的适配和管理更加灵活。
- 在具体的注入实现中，接口注入（Type 1 IoC）,setter注入（Type 2 IoC）,构造器注入（Type 3 IoC）是主要的注入方式。在Spring的IoC设计中，setter注入和构造器注入是主要的注入方式；相对而言，使用Spring时setter注入是常见的注入方式，而且为了防止注入异常，Spring IoC容器还提供了对特定依赖的检查。
- 另一方面，在应用管理依赖关系时，可以通过IoC容器将控制进行反转，在反转的实现中，如果能通过文本来完成配置，并且还能通过工具对这些配置信息进行可视化的管理和浏览，那么肯定是能够提高对组件关系的管理水平，并且如果耦合关系需要变动，并不需要重新修改和编译Java源码，这符合在面向对象设计中的开闭准则，并且能够提高组件系统设计的灵活性，同时，如果结合OSGi的使用特性，还可以提高应用的动态部署能力。
- 在具体使用Spring IoC容器的时候，我们可以看到，Spring IoC容器已经是一个产品实现。作为产品实现，它对多种应用场景的适配是通过Spring设计的IoC容器系列来实现的，比如在某个容器系列中可以看到各种带有不同容器特性的实现，可以读取不同配置信息的各种容器，从不同I/O源读取读取配置信息的各种容器设计，更加面向框架的容器应用上下文的容器设计等。
推荐阅读