我们从应用场景出发。
假如有一个图书管理系统，要实现这个项目，你肯定是要写service层和Dao层的对吧。通常情况下，我们一般给出下面这样的实现。
//业务层实现类
public class BookServiceImpl implements BookService {
private BookDao bookDao = new BookDaoImpl;
public void save() {
bookDao.save();
}
}
//数据层实现
public class BookDaoImpl implements BookDao {
public void save() {
System.out.println("book dao save...");
}
}
这是一种很常见的写法。
但是这样的写法耦合度太高，有些同学可能不理解什么叫“耦合度”，可以简单的理解为：两个类之间的关联程度，耦合度高就代表两个类之间关联程度很高，动其中一个类，就不得不动另外一个类。
假如我们此时Dao层的实现要变，要写一个新类。
public class BookDaoImpl2 implements BookDao {
public void save() {
System.out.println("book dao save2...");
}
}
service必然也要改变，因为service的实现依赖dao层，而这一变可好，项目得停止，重新测试、调试、重新部署。。。
这一改不要紧，带来的成本可是相当的大，要知道，企业里时间就是金钱。
于是我们想，如果service层不newDao层的对象，改为你service啥时候用dao对象，我外部提供Dao对象给service，外边随便改，我service自岿然不动，这不就解决了吗？
于是就有人提出了IoC思想（Inversion of Control）
对你没听错，IoC是一种思想
IoC思想：程序的控制权由程序转移到外部，这种思想称为控制反转
这就做到了解耦。
//业务层实现类
public class BookServiceImpl implements BookService {
private BookDao bookDao;//service:我免费啦！
public void save() {
bookDao.save();
}
}
而Spring呢，就实现了IoC思想，具体是怎么实现的？那就要问问IoC容器了。
IoC容器我们上面体系结构图中清楚的可以看到，Spring创建了一个IoC容器。
什么是IoC容器？
就是一个容器，字面意思的“容器”明白吗，就像是一个碗，里面放的不是麻辣烫，放的是对象。
IoC容器负责对象的创建、初始化等一系列操作。
而Spring实现IoC思想，就是借助IoC容器实现的。
具体是这样：不是说好service不主动new Dao对象了吗。你service啥时候用dao对象，我给你！这里的“我”是谁？那便是I O C 容 器。
同样，dao的对象可以放在IoC容器里，你凭什么歧视我service对象。
IoC容器：好，都到碗里来！
于是啊，IoC容器就像火烧，把驴肉对象都加进去了。
但是这样还有一个问题，就是你一个项目肯定很多驴肉，不是，我是说对象。
比如像上面，BookServiceImpl对象依赖BookDaoImpl对象（因为前者里面要用到后者，所有前者得持有后者的对象，才能用后者的方法。这叫依赖）
那我火烧里面那么多驴肉，谁知道那两片驴肉之间是什么依赖不依赖关系。
这事儿，得问问DI。
DI（Dependency Injection）依赖注入
DI：我就是管IoC容器中有依赖关系的类之间关系的建立的，我名字起这么明显听不出来？。
路人：奥，民政局老哥你好！
DI：(ノ｀Д)ノ滚！
bean：扯半天犊子，我呢？
是这样，IoC容器这个人占有欲和控制欲很强。把所有的对象都吃进去就算了，还必须给IoC容器肚子里的对象们起一个统一的名字，这些对象统一叫为，bean
bean：原来我是一群对象的名字！
行了，溜了。有问题的评论区交流。
