1 在spring开发指南中有这么一段话
这里暂且抛开Spring Framework在设计上相当出彩的表现不谈。站在应用开发的实际角度来说，
其最大的优势在于：Spring是一个从实际项目开发经验中抽取的，可高度重用的应用框架。认识到这
一点非常重要。
Spring Framework中目前最引人注目的，也就是名为控制反转（IOC ＝Inverse Of Control）
或者依赖注入（DI ＝Dependence Injection）的设计思想，这的确是相当优秀的设计理念，但是，
光一个单纯的设计模式并不能使得Spring如此成功，而Spring最成功的地方也并不仅仅在于采用了
IOC/DI的设计。我们前面示例中的ActionFactory，勉强也可算做是一个IOC/DI设计的实现，但又如
何？
可能相关技术媒体和不明就里的技术追随者对于DI/IOC容器的过分炒作，在某种程度上误导了初学
者的视线。“控制反转”，这显然不是一个能望文知意的好名称；“依赖注入”，也好不到哪里去，也正因
为这样，不少初学者都将Spring和生涩的所谓“控制反转”和“依赖注入”看作一个懵懂的高级概念而
供上了神龛。
而实际上，Spring是笔者所见过的，最具实际意义的Java开发框架。它绝非一个高级概念玩具，而
是一个切实的，能实实在在帮助我们改善系统设计的好帮手。
首先，Spring涵盖了应用系统开发所涉及的大多数技术范畴，包括MVC、ORM以及Remote
Interface等，这些技术往往贯穿了大多数应用系统的开发过程。Spring从开发者的角度对这些技术内
容进行了进一步的封装和抽象，使得应用开发更为简便。在笔者的开发工作中，借助Spring提供的丰富
类库，相对传统开发模式，大大节省了编码量（平均1/3强，对于ORM和Remote层也许更多）。
其次，Spring并非一个强制性框架，它提供了很多独立的组件可供选择。如笔者在一些项目中，就
仅引用了Spring的ORM模板机制对数据存取层进行处理，并取得了相当理想的效果。
评定一个框架是否优良的条件固然有很多种，但是笔者始终认为，对于应用系统开发而言，我们面
临着来自诸多方面的压力，此时，最能提高生产力的技术，也就是最有价值的技术。很高兴，Spring让
笔者找到了这样的感觉。
笔者对Rod Johnson最为钦佩的，并不是他用了IOC或者DI，而是他对J2EE应用开发的透彻的理
解。
他真的明白开发人员需要什么。
Type2和Type3型的依赖注入实现则是目前主流的IOC实现模式。这两种实现方式各有特点，也各具
优势（一句经典废话J）。
Type2 设值注入的优势
1． 对于习惯了传统JavaBean开发的程序员而言，通过setter方法设定依赖关系显得更加直
观，更加自然。
2． 如果依赖关系（或继承关系）较为复杂，那么Type3模式的构造函数也会相当庞大（我们需
要在构造函数中设定所有依赖关系），此时Type2模式往往更为简洁。
3． 对于某些第三方类库而言，可能要求我们的组件必须提供一个默认的构造函数（如Struts
中的Action），此时Type3类型的依赖注入机制就体现出其局限性，难以完成我们期望的功
能。
Type3 构造子注入的优势：
1． “在构造期即创建一个完整、合法的对象”，对于这条Java设计原则，Type3无疑是最好的
响应者。
2． 避免了繁琐的setter方法的编写，所有依赖关系均在构造函数中设定，依赖关系集中呈现，
更加易读。
3． 由于没有setter方法，依赖关系在构造时由容器一次性设定，因此组件在被创建之后即处于
相对“不变”的稳定状态，无需担心上层代码在调用过程中执行setter方法对组件依赖关系
产生破坏，特别是对于Singleton模式的组件而言，这可能对整个系统产生重大的影响。
4． 同样，由于关联关系仅在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系。
对调用者而言，组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息，也为系统的
层次清晰性提供了保证。
5． 通过构造子注入，意味着我们可以在构造函数中决定依赖关系的注入顺序，对于一个大量
依赖外部服务的组件而言，依赖关系的获得顺序可能非常重要，比如某个依赖关系注入的
先决条件是组件的DataSource及相关资源已经被设定。