继第一节。
（1）IOC与DI的理解
IOC（Inversion of Control）:其思想是反转资源获取的方向，传统的资源获取方式需要组件向容器索取，作为回应，容器返回资源给组件。而应用了IOC以后，容易主动的将资源推送给组件，组件需要做的是以一种合适的方式接受资源（例如setter、构造器）。这种行为也被称为被动形式。
DI（Dependency Injection）--IOC另一种表达形式：即组件以一些预定好的方式（setter）接受来自容器的资源。相较于IOC，这种表述更为直接。
举例：买菜。传统的买菜就是我们到菜市场挑选菜，然后放到篮子里买回来。是我们主动去买菜。
采用IOC的思想，还是买菜，但是我们不需要去菜市场了，会有人把菜送到我们家来。这样买菜就变得被动了。
实例
举个小例子把，运用到框架如SSH的时候，我们在action（控制器类）里会需要用到数据库dao层的类，一般我们会有业务层biz，用于做action与dao之间的桥梁，如果不采用IOC，在action里面会需要dao层，和biz层的实例，这样增加业务逻辑的耦合度，为了降低这种耦合度，我们用到IOC，在IOC容器里面装配，我们就不需要dao，和biz层的实例了，只需要在action里面添加接受方法(setter)即可。等于说dao依赖注入进了biz。
（2）IOC的由来
①IOC前生---分离接口与实现
这个类图的理解是这样的：我们有个报表服务站（ReportService）需要接受报表，有两个报表生成器PdfReportGenerator, HtmlReportGenerator。这两个生成器继承ReportGenerator接口。最原始的方式，我们在报表服务站用到这两种生成器，需要知道这个生产器和它的父类接口，耦合度极高，可能这张图看不出什么，但是如果报表生成器有一万个呢，那我们的服务站是不是需要知道这一万个报表的生产方式？
②IOC前生---采用工厂设计模式
继分离接口实现来说，工厂模式跨出了一步，我们建立一个工厂用来生产PdfReportGenerator报表和HtmlReportGenerator报表，这个工厂继承ReportGenerator接口，我们的报表站只需要知道工厂和ReportGenerator接口就可以了，具体的报表生产方式并不需要知晓，报表的生产交给工厂来做，做好了交给服务站。这样耦合程度就有了大大改善。
③IOC---控制反转
在IOC的模式下，报表服务站只需要知道ReportGenerator接口和提供setter方法接受即可，其他的交给IOC容器来处理。IOC容器主动找到这个组件，为这个组件注入值（需要在配置信息里提供PdfReportGenerator的bean信息）。这样看来报表服务站就轻松多了，它只需要知道一个借口，其他的类会由IOC主动给你。我们就可以在服务站痛痛快快的写业务代码啦。