Spring的依赖注入及三种配置方式(上)

为什么要引入依赖注入

在解决这个问题前我们要先回答以下几个问题：

什么是依赖？

Spring IoC容器的依赖有两层含义：Bean依赖容器和容器注入Bean的依赖资源：

Bean依赖容器：这里的依赖是指容器负责创建Bean并管理Bean的生命周期，正是由于由容器来控制创建Bean并注入依赖，也就是控制权被反转了，这也正是IoC名字的由来，此处的有依赖是指Bean和容器之间的依赖关系。

容器注入Bean的依赖资源：容器负责注入Bean的依赖资源，依赖资源可以是Bean、外部文件、常量数据等，在Java中都反映为对象，并且由容器负责组装Bean之间的依赖关系，此处的依赖是指Bean之间的依赖关系，可以认为是传统类与类之间的“关联”、“聚合”、“组合”关系。

什么是依赖注入？

针对本次的实验，画了如下的图，来大致表示依赖注入。

可以看到，在Spring中，对象的生成不再是通过显式的new，而且到spring容器里面取，对象的创建是使用注入这种形式。

image

相比于new一个对象，依赖注入有哪些优势呢？

比如说有一个订单的DAO接口：interface OrderDAO

在开发的时候用的MySql数据库，实现类为 class MySqlOrderDAOImpl implements OrderDAO

在业务代码里面，要使用OrderDAO，这没什么难的，直接new一个对象不就行了吗，于是就这样：

OrderDAO dao = new MySqlOrderDAOImpl();

轻松完成，最后项目完成，实施运营了，后来客户发现MySql不行了，要换成Oracle，这不难，再写一个OrderDAO的实现类不就行了吗：

class OracleOrderDAOImpl implements OrderDAO

可是这样就又来了一个麻烦就是在业务代码里面，都是自己new的对象，都是“MySqlOrderDAOImpl”，

没问题，把 “MySqlOrderDAOImpl” 替换成”OracleOrderDAOImpl “就可以了

于是，全体动员，查找“MySqlOrderDAOImpl”然后替换成”OracleOrderDAOImpl “，这样浪费了半天，还可能有些地方还没替换呢

而如果使用spring的Ioc，在配置文件里配置OrderDAO的实现类就可以了，只要OrderDAO的有新的实现类，只需要在配置文件中修改一下就可以了，大概需要几秒钟吧，时间太快，没法计算啊。

实例化相比于依赖注入的优点：
优点：快，适用于小项目
缺点：不利于测试，维护、以及多人开发

依赖注入确实很方便，但是如果某个类的实例化需要参数呢?

可以通过构造器注入和属性注入。
构造器注入
在进行依赖获取的时候，框架找到待创建类的构造方法，然后根据构造器所需参数的类型或者顺序，容器节点中寻找，然后提供参数，创建实例。
属性注入
同样的，找到待创建类型的所有属性，然后根据属性在容器节点中进行匹配，有则创建提供，无则跳过。

这两种注入方式将在后面的实验里介绍。

为什么要引入依赖注入呢？

依赖注入不是目的，它是一系列工具和手段，最终的目的是帮助我们开发出松散耦合、可维护、可测试的代码和程序。
依赖注入让使用者不需要自己去创建或获取自己的依赖，既然创建或获取的过程不是使用者控制的，这也就意味着，当需要切换依赖时，不需要改变使用者的代码。
可以让spring去管理对象A。比如在B中使用A很多，哪一天A大量更改，那么B中就要修改好多代码。倘若使用spring托管，也就是Ioc。那么A改它的。只需要在spring配置文件中修改A的相关配置即可。AB间耦合降低了修改代码的负担。而且也解耦合，符合软件工程的思想。
总结来说依赖注入大概有两个好处：解耦，方便单元测试。