关于Spring IOC与Spring AOP的总结

一、概述

spring 的ioc解决的是对象之间的依赖的问题。spring 的aop解决的是业务逻辑和系统公用模块之间的解耦的问题。

他将系统公用的模块，比如事务处理、安全监听、打印日志等等模块，作为横切关注点，在不破坏原有业务逻辑的前提下，插入业务逻辑层。这样就相当于在业务逻辑层插入了一些公用模块的组件，来帮助我们监听系统的运行情况。

在涉及到公共模块的修改的时候，不用在连接点附近一个一个修改，而是只要修改公用的那个模块就可以了（即横切关注点）。这样就实现了横切关注点和业务逻辑之间的解耦。

Spring默认使用JDK动态代理实现AOP代理。这使得任何接口或 接口的集合能够被代理。Spring也可以是CGLIB代理。这可以代理类，而不是接口。

二、总结

（1）spring ioc

spring ioc是通过spring框架的封装，实现了依赖的反转，即：不是项目依赖于容器，而是容器为项目提供服务。

换句话说，原本传统模式下，我们是先创建项目，然后手动的建立容器，容器里面再注入各种各样的实体类，塞满容器。这样做，我们会很累，因为当你的项目越来越大的时候，光是一个jdbc的容器，我们就要注入很多层。

反之，如果我们在项目启动的时候，就先把这些需要使用到的容器，通过spring先完成依赖关系的注入，那么我们在项目中，需要使用这些组件的时候，就可以直接使用了，就不用再一次一次的手动注入、生成这些组件了。

这也就是不是项目依赖于容器，而是容器为项目提供服务这句话的深层次含义。

（2）spring aop

spring aop做的事情，和spring ioc有相似之处。

他们两个都实现了代码的解耦，ioc解耦了项目和容器之间的耦合。而aop解耦了核心业务逻辑层和辅助功能层（比如：事务处理、日志打印、安全监控等等）之间的耦合。

spring ioc是完成组建的注入，让我们在项目中可以直接使用，而不用一次次的手动注入，减少了我们的冗余代码。

而spring aop的实现逻辑则不同：

假设项目的业务逻辑层已经完善，但是我们需要在A、B、C业务中加入不同的辅助功能（之所以叫做辅助功能，是因为这些功能是不影响业务逻辑的）比如，A业务是事务处理。B事务是安全监听。C事务是日志打印。

你可以看到A、B、C三个业务对于我们原本的核心业务逻辑是不产生任何影响的。

我们传统的做法是，每次遇到A、B、C业务的时候，都自己去手写，这样当然是可以的。

但是，有没有更好的方式？有，spring AOP就提供了这样的解决办法。

我们在spring aop 中，主要是基于动态代理，将业务逻辑的方法调用点做了分隔或者说打断，打断之后，我们可以在这个方法的调用点前后，加上自定义的方法。

这样做的好处是在于：

1.打断之后，我们可以将A、B、C三个业务模块写到一个公共的地方，减少了冗余代码，提升了代码的可维护性。

2.我们可以将打断的所有点，称为切入点，我们可以管理这些切入点。

3.我们可以对目标类进行引入（增加方法或字段）。

4.将辅助功能和业务逻辑解耦，两者非耦合，提升了代码的灵活度。

也就是说，当我需要将辅助层（比如：事务管理逻辑层、性能监视逻辑层）的功能做优化和改动的时候，不会涉及业务逻辑层的代码的修改，不会影响业务逻辑层的运行。

实际上，spring aop运用了代理，代理能够将类和方法作为参数，通过其中封装的方法来调用任意被代理类的任意方法（当然接口也可以被代理）。正因为代理的这个特性，使得spring aop具备了某种类似于打断的功能：我只要把你这个类代理了，然后我在你调用前后，加上我的横切关注点(辅助功能模块)就好了。