javaConfig、控制反转(IOC)与依赖注入(DI)

java config是指基于java配置的spring * 每年桃花开的时候*
传统的Spring一般都是基本xml配置的 我就会想起一个人，
JavaConfig就是使用注释来描述Bean配置的组件 她曾经很喜欢我
JavaConfig 是Spring的一个子项目 怎么？想回家乡了？
比起Spring，它还是一个非常年轻的项目 要是为了这个就回家乡

@EnableWebMvc

相当于xml的 为什么当初你要出来

< mvc:annotation-driven> ~~他说~~

@ImportResource

相当于xml的 人最大的烦恼就是记性太好
< import resource=“applicationContext-cache.xml”> 如果可以把所有的东西都忘掉

@PropertySource

spring 3.1开始引入， 以后的每一天将会是一个新的开始
它是基于java config的注解， 我在qf刷知乎的日子
用于读取properties文件 我在深夜假装网易云的时光

@Profile

spring3.1开始引入,一般用于多环境配置，激活时可用@ActiveProfiles注解,@ActiveProfiles(“dev”)

@Configuration

在类上打上这一标签，表示这个类是配置类

@ComponentScan

就是根据定义的扫描路径，把符合扫描规则的类装配到spring容器中

相当于xml的
<context:componentscan basepakage=>

@Bean

bean的定义，相当于xml的
<beanid="objectMapper"class=“org.codehaus.jackson.map.ObjectMapper” />

Spring IOC有一个非常核心的概念——Bean。
由Spring容器来负责对Bean的实例化，装配和管理。
这其实引出了两个我们常常谈到的概念
–控制反转（inversion of control）、依赖注入(dependency injection)

那么其中ioc和di的之间存在什么关系？

首先先了解什么是控制反转（IOC）

借助于“第三方”实现具有依赖关系的对象之间的解耦，看图：

使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的转动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似**“粘合剂”**的作用，

如果我们把IOC容器拿掉

这时候，A、B、C、D这4个对象之间已经没有了耦合关系，彼此毫无联系，这样的话，当你在实现A的时候，根本无须再去考虑B、C和D了，对象之间的依赖关系已经降低到了最低程度

“控制反转”的由来：
由于IOC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
通过前后的对比，我们不难看出来：对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是控制反转这个名称的缘起。

再来看看何谓依赖注入

其实由上面我们就了解到，对象A获得依赖对象B的过程，这个过程便是依赖注入，
依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。
我们再细细道清
举个栗子：
我们利用电脑主机和USB接口来实现一个任务：从外部USB设备读取一个文件。
电脑主机读取文件的时候，它一点也不会关心USB接口上连接的是什么外部设备，而且它确实也无须知道。它的任务就是读取USB接口，挂接的外部设备只要符合USB接口标准即可。所以，如果我给电脑主机连接上一个U盘，那么主机就从U盘上读取文件；如果我给电脑主机连接上一个外置硬盘，那么电脑主机就从外置硬盘上读取文件。挂接外部设备的权力由我作主，即控制权归我，至于USB接口挂接的是什么设备，电脑主机是决定不了，它只能被动的接受。电脑主机需要外部设备的时候，根本不用它告诉我，我就会主动帮它挂上它想要的外部设备，你看我的服务是多么的到位。这就是我们生活中常见的一个依赖注入的例子。在这个过程中，我就起到了IOC容器的作用。
通过这个例子,依赖注入的思路已经非常清楚：当电脑主机读取文件的时候，我就把它所要依赖的外部设备，帮他挂接上。整个外部设备注入的过程和一个被依赖的对象在系统运行时被注入另外一个对象内部的过程完全一样。

相关连接：
javaConfig
IOC与DI
代码尽头谁为峰
一见侯哥道成空