Spring是轻量级的且是非侵入式的
1. 深入理解依赖注入
依赖注入(DI)也被称为控制反转(IoC)，两者的含义相同，只是从两个角度来描述同一个概念。但是对于Spring初学者来说，这两种说法同样生涩难懂，因此，我们尝试用更加简单通用的语言和例子来描述出这个概念。
用一句话概括依赖注入就是" 不要来找我，我会去找你 "，也就是说，一个类不需要去查找或实例化他们所依赖的类。对象间的依赖关系是在对象创建时由负责协调项目中各个对象的外部容器提供并管理的。也就是强调了对象间的某种依赖关系是有容器在运行期间注入调用者的，控制程序间关系的实现交给了外部的容器来完成。
在原来我们可能会使用工厂模式来进行解决掉这个问题。工厂模式专门负责对大量有共同接口的类进行实例化。工厂模式可以动态地决定应该将哪一个类实例化，而无需事先知道每次要实例哪一个类。
但是，如果使用Spring的话，就会比之还要简单。DI就是将协调对象之间合作的任务从对象本身转移出来，而由Spring框架来负责。IoC是由容器来控制程序之间的关系，而不是有程序代码直接控制。控制权由应用代码转移到了外部容器，控制权发生了反转。
2. 依赖注入的3种实现方式
2.1 设值注入
设值注入是指IoC容器使用Setter方法来注入被依赖的实例。通过调用无参构造器或无参static工厂方法实例化bean后，调用bean的setter方法，即可实现基于setter的DI。
PS：我们上一节中，所介绍的程序就是一个简单的设值注入，所以这里就不再进行介绍了。
2.2 构造方法注入
构造方法注入是指IoC容器使用构造方法来注入被依赖的实例。基于构造器的DI通过调用参数的构造方法来实现，每个参数代表着一个依赖。下面展示了只能使用构造方法参数来注入依赖关系的例子。请注意，这个类并没有什么特别之处，仍然是一个普通的Java类。
- 在实现类中添加构造方法，并且是带有参数的构造方法。在其中一个参数也就是一个依赖关系。
- 在beans.xml，也就是配置文件中修改代码，将原有的注入方式进行更改
<constructor-arg> <ref bean="u"/> </constructor-arg>
这一句代码就是能等同与上面的程序中，我们的setter注入方式进行注入的。
2.3 接口注入
接口注入需要我们的类实现特定的接口或继承特定的类。但是这样一来，我们的类就必须依赖于这些特定的接口或特定的类，这也意味着侵入性。Apache开源的Avalon和EJB容器属于这一类。但是因为它的侵入性，这种注入方式基本上已经被遗弃了。Spring是轻量级的、非侵入性的框架，故其并不支持接口注入。
2.4 DI 3种实现方式的比较
1.设值方法注入的优点
- 对于习惯传统的JavaBean开发的程序人员来说，通过setter方法注入属性值是熟悉的、直观的和自然的。
- 如果依赖关系比较复杂，那么构造方法注入方式会导致构造方法相当庞大，此时使用设置方法注入更为简洁。
2.设值方法注入的缺点
- 设值方法注入需要对每个需要注入的类属性定义setter方法。这种注入具有很大的灵活性，但容易破坏类的状态和行为。例如，一个类有两个属性a和b，还有一个方法是用来实现a和b的加法。如果我们只设置了a的值 而没有设置b的值就直接调用加法，那么肯定会出错，所以，在设置属性时，我们必须知道哪些属性组合是有效的，那些是无效的。而且这些属性的设置顺序也是需要注意的。
3.构造方法注入的优点
- 构造方法很好的响应了Java的设计原则之一，在构造期间即创建一个完整的、合法的对象。
- 避免了繁琐的setter方法的编写，所以的依赖关系均在构造方法中设定，依赖关系集中体现，更加易读。
- 关联关系仅在构造方法中表达，故只有组件创建者需要关系组件内部的依赖关系。对调用者而言，组件中的依赖关系处于黑盒子之中，对上层屏蔽不必要的信息，也为系统的层次清晰性提供了保证。
4.构造方法的缺点
- 首先，构造方法里出现错误有时是很难查的
- 其次，在继承中，构造方法是不会自动继承下去的，必须要手动来完成。
- 最后，它很难处理一些特殊情况，例如，不是必须的而是可选的属性，循环的依赖关系等。
所以，就一般的项目开发来说，以设值方法注入为主，辅以构造方法注入为补充，可以达到最好的开发效率。
