一、IOC(DI)
Inversion of Control 控制反转，也叫（Dependency Injection）依赖注入。
我们平常使用对象的时候，一般都是直接使用关键字类new一个对象，那这样有什么坏处呢？其实很显然的，使用new那么就表示当前模块已经不知不觉的和 new的对象耦合了，而我们通常都是更高层次的抽象模块调用底层的实现模块，这样也就产生了模块依赖于具体的实现，这样与我们JAVA中提倡的面向接口面向抽象编程是相冲突的，而且这样做也带来系统的模块架构问题。
很简单的例子，我们在进行数据库操作的时候，总是业务层调用DAO层，当然我们的DAO一般 都是会采用接口开发，这在一定程度上满足了松耦合，使业务逻辑层不依赖于具体的数据库DAO层。但是我们在使用的时候还是会new一个特定数据库的DAO 层，这无形中也与特定的数据库绑定了，虽然我们可以使用抽象工厂模式来获取DAO实现类，但除非我们一次性把所有数据库的DAO写出来，否则在进行数据库 迁移的时候我们还是得修改DAO工厂类，所以我们就思考新的方法
使用IOC，就是DAO接口的实现不再是业务逻辑层调用工厂类去获取，而是通过容器（spring）来自动的为我们的业务层设置DAO的实现类，这样整个过程就反过来，以前是我们业务层主动去获取DAO，而现在是DAO主动被设置到业务逻辑层中来了，这也就是反转控制的由来。通过IOC，我们就可以在不修改任何代码的情况下，无缝的实现数据库的换库迁移
二、AOP
Aspect Oriented Programming 面向切面编程。
假设我们要在方法的开始和结束处加上一些业务逻辑,大家想到的最直接的方法，就是在方法前面和后面加上一些代码，如日志，假如不能改变原来的方法了，那你又会想到继承类，重写方法。可能你又会想到，组合的方式。假设现在要把这个日志功能加入到20个不同方法的前面，可以考虑把那个日志功能抽离出来封装成一个类的方法，但是那样还是要组合新建20个类，组合20次。
这样肯定不可靠。我们想新的思路，可以写一个配置文件，在每个需要加日志逻辑的里面，类的所有方法上配上那个日志类的方法，这样就不用新建20个类，组合20次旧的类，但是问题又来了，程序不会返回你重新组合的那个类（即那个新组合而成的动态类），我们需要思考新的方法。
使用AOP,就可以解决，他帮助我们生成动态的代理类，织入新的业务逻辑，如事务，日志等等。
Spring中的IOC和AOP