前言
我们都知道Spring 框架主要的优势是在 简化开发 和 框架整合 上，至于如何实现就是我们要学习Spring 框架的主要内容，今天我们就来一起学习Spring中的两大核心技术IoC（控制反转）与DI（依赖注入）。
文章目录
- 前言
- 一、传统方式创建对象的弊端
- 1.控制器层(Controller)
- 2.业务层(Service)
- 3.数据库访问层(Dao)
- 4.问题分析
- 二、IoC(控制反转)
- 2.1、IoC：Inverse of Control（控制反转）
- 2.2、生活案例
- 三、DI(依赖注入)
- 3.1DI：Dependency Injection（依赖注入）
- 3.2生活案例
- 总结：
一、传统方式创建对象的弊端
以经典的三层架构MVC作为案例，以前我们都是这么干的，看如下代码：
1.控制器层(Controller)
// 用户控制器
public class UserServlet{
private UserService userService = new UserServiceImpl();
public void doGet(HttpServletRequest request, HttpServletResponse response){
// ...
userService.login();
// ...
}
}
2.业务层(Service)
// 用户Service接口
public interface UserService{
public User login(String uname,String pwd);
}
// 用户Service实现类
public class UserServiceImpl implements UserService{
private UserDao userDao = new UserDaoImpl();
public User login(String uname,String pwd){
userDao.selectByUnameAndPwd(uname,pwd);
}
}
3.数据库访问层(Dao)
// 用户Dao接口
public interface UserDao{
public User selectByUnameAndPwd(String uname,String pwd);
}
// 用户Dao实现
public class UserDaoImpl implements UserDao{
public User selectByUnameAndPwd(String uname,String pwd){
// 编写sql语句
}
}
4.问题分析
按照以前的做法，可以发现，我们的UserServlet要依赖UserServiceImpl实现，UserServiceImpl要依赖UserDaoImpl实现，一个很明显的问题是：对于这些具体的实现类是由我们程序员自己去主动手动创建(new)出来的，那么意味着假如某个实现类发生了变化，将可能导致整个应用的不可用（编译不通过等），那么这个问题的本质原因就在于这个具体的类是我们自己硬编码到Java类中的。
试想：能否有一种方式可以实现在不改变代码的前提下实现自如的切换具体的实现类呢？答案是可以的，那么我们可以将创建这个实现类的工作交给别人来做，而我们就不再去自己主动创建类的对象了。那么解决方案就是：Spring的Ioc。
二、IoC(控制反转)
创建对象的工作不是由程序员主动去创建，而是交给了框架，比如说Spring，那么这个时候我们称创建对象的控制权交给了其他人，那么就称之为控制反转。
2.1、IoC：Inverse of Control（控制反转）
- 什么是控制反转呢？
使用对象时，由主动 new 产生对象转换为由 外部 提供对象，此过程中对象创建控制权由程序转移到 外部，此思想称为控制反转。
业务层要用数据层的类对象，以前是自己new的 现在自己不new了，交给别人(外部)来创建对象 别人(外部)就反转控制了数据层对象的创建权。
这种思想就是控制反转
- Spring 和 IOC 之间的关系是什么呢 ?
Spring技术对IOC思想进行了实现 Spring提供了一个容器，称为IOC容器，用来充当IOC思想中的”外部”。
IOC思想中的别人(外部)指的就是Spring的IOC容器。
- IOC 容器的作用以及内部存放的是什么 ?
IOC容器负责对象的创建、初始化等一系列工作，其中包含了数据层和业务层的类对象 被创建或被管理的对象在IOC容器中统称为Bean。
IOC容器中放的就是一个个的Bean对象。
- 当 IOC 容器中创建好 service 和 dao 对象后，程序能正确执行么 ?
不行，因为service运行需要依赖dao对象 IOC容器中虽然有service和dao对象，但是service对象和dao对象没有任何关系。
需要把dao对象交给service,也就是说要绑定service和dao对象之间的关系。
- IOC不是什么技术，而是一种设计思想，就是将原本在程序中手动创建对象的控制权，交由Spring框架来管理。
- 若要使用某个对象，只需要从 Spring 容器中获取需要使用的对象，不关心对象的创建过程，也就是把创建对象的控制权反转给了Spring框架
2.2、生活案例
在现实生活中，人们要用到一样东西的时候，第一反应就是去找到这件东西，比如想喝新鲜橙汁，在没有饮品店的日子里，最直观的做法就是：买果汁机、买橙子，然后准备开水。值得注意的是：这些都是你自己**“主动”创造**的过程，也就是说一杯橙汁需要你自己创造。
然而到了今时今日，由于饮品店的盛行，当我们想喝橙汁时，第一想法就转换成了找到饮品店的联系方式，通过电话等渠道描述你的需要、地址、联系方式等，下订单等待，过一会儿就会有人送来橙汁了。
注意：你并没有“主动”去创造橙汁，橙汁是由饮品店创造的，而不是你，然而也完全达到了你的要求，甚至比你创造的要好上那么一些。
所以控制反转IoC(Inversion of Control)是说创建对象的控制权进行转移，以前创建对象的主动权和创建时机是由自己把控的，而现在这种权力转移到第三方，比如转移交给了IoC容器，它就是一个专门用来创建对象的工厂，你要什么对象，它就给你什么对象，有了 IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器了，通过IoC容器来建立它们之间的关系。
三、DI(依赖注入)
3.1DI：Dependency Injection（依赖注入）
含义：
- 指 Spring 创建对象的过程中，将对象依赖属性（简单值，集合，对象）通过配置设值给该对象
- 具体什么是依赖注入呢 ?
在容器中建立 bean 与 bean 之间的依赖关系的整个过程，称为依赖注入，业务层要用数据层的类对象，以前是自己new的。
现在自己不new了，靠别人(其实指的就是IOC容器)给注入进来，这种思想就是依赖注入。
- IOC 容器中哪些 bean 之间要建立依赖关系呢 ?
这个需要程序员根据业务需求提前建立好关系，如业务层需要依赖数据层，service就要和dao建立依赖关系。
3.2生活案例
图中三个设备（笔记本电脑一台、USB 硬盘和U 盘）都有一个共同点，都支持USB 接口。当我们需要将数据复制到外围存储设备时，可以根据情况，选择是保存在U 盘还是USB 硬盘，下面的操作大家也都轻车熟路，无非接通USB 接口，然后在资源浏览器中将选定的文件拖放到指定的盘符。
这样的操作在过去几年中每天都在我们身边发生，而这也正是所谓依赖注入的一个典型案例，再看上例中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB ）相连，对于笔记本而言，只是将用户指定的数据发送到USB 接口，而这些数据何去何从，则由当前接入的USB 设备决定。
在USB 设备加载之前，笔记本不可能预料用户将在USB 接口上接入何种设备，只有USB 设备接入之后，这种设备之间的依赖关系才开始形成。
对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows 操作系统）将依赖关系（笔记本依赖USB 设备进行数据存取）注入到组件中（Windows 文件访问组件）。这就是依赖注入模式在现实世界中的一个版本。
总结：
- IoC 和 DI 其实是同一个概念的不同角度
- 描述，DI 相对 IoC 而言，明确描述了“被注入对象依赖 IoC 容器配置依赖对象”
IoC/DI这两个概念的最终目标就是 : 充分解耦 ，具体实现靠 :
使用IOC容器管理bean（IOC)
在IOC容器内将有依赖关系的bean进行关系绑定（DI）
最终结果为：使用对象时不仅可以直接从IOC容器中获取，并且获取到的bean已经绑定了所有的依赖关系。
理解了IoC和DI的概念后，一切都将变得简单明了，剩下的工作只是在spring的框架中堆积木而已。
Spring学习路线：
下篇文章中，我将带大家以HelloWorld为例，编写一个程序，让创建对象的工作由Spring帮助我们创建，一起体验Spring带给我们的开发便利。
文章出处登录后可见！
