关于Spring AOP

把SpringAOP拿出来单独开一个帖子，这样比较醒目，不得不说现在面试的时候，SpringAOP将会被很多人作为面试题来考察你的技术基础，这个AOP还是有必要好好的学一下的。

什么是AOP？AOP可以干什么？
AOP为Aspect Oriented Programming的缩写，意为：面向方法编程
在软件开发中，散布于程序多个点的函数被称为交叉事务。它们一般是与程序业务逻辑分开的，把这些交叉事务与业务逻辑分开正是AOP的作用。
重用公共功能的常见面向对象技术就是继承与委托。但是在程序中反复使用一个基类可能会形成很脆弱的对象体系，而使用委托需要对委托对象进行复杂的调用。
切面提供了一种取代继承和委托的方式，在使用面向切面编程时，我们仍然是在一个地方定义公用功能，但可以明确地定义这个功能在哪、以何种方式运行，并且不必修改会受影响的类。这样一来，交叉事务就可以被模块化到特殊的对象里，这些对象就被称为“切面”。这样做的好处就是每个事务的逻辑位于一个位置，而不是分散到多处代码。其次，服务模块更简洁，因为它们只包含用于主要功能的代码，辅助事务的代码被转移到切面。

上面是对AOP的一些介绍吧，了解一下就可以，通过下面的例子就能很快的明白AOP可以干什么了。

Adice（通知）
通知定义了切面是什么以及何时使用，除了描述切面要完成的工作，通知还解决了何时执行这个工作的问题。它应该应用在某个地方被调用之前？还是之后？或者只在方法抛出一个异常时？
下面有一个表演和观众的例子:


通过以上的例子我们可以看出在表演之前要入座、关手机，表演成功后鼓掌，表演失败观众会要求退票。这样做确实是可以的，但PerformerImpl必须要告诉Audience应该怎么做，这就有点奇怪了，表演者应该只负责表演，而不是提示观众应该做反应，而观众应该根据自己的判断做出反应。而且如果有多个表演者，那每个表演者都要注入Audience，并且要自己去写必须调用的方法，这样就紧紧的耦合在一起并互相依赖，就像表演者没有观众就不能表演一样。


创建通知：
正如前面介绍那样，通知定义了切面的功能以及何时使用，而切面就是把交叉事务模块化到特殊的对象里，而这个对象就是切面。
根据前面的例子，可以看出落座和关手机属于前通知来执行，鼓掌是返回后通知，而退票则适合抛出后通知。下面来看一下这个特殊的对象—“切面”:

AOP的通知有5种形式通知类型 接口
Before(前) org.springframework.aop.MethodBeforeAdvice
After-returning(返回后) org.springframework.aop.AfterReturningAdvice
After-throwing（抛出后） org.springframework.aop.Throws
AdviceAround（周围） org.aopalliance.intercept.MethodInterceptor
Introduction(引入) org.springframework.aop.IntroductionInterceptor
除了MethodInterceptor（周围通知）之外，其他接口都属于Spring框架，这些通知都利用到AOP Allinance提供的接口，这是一个开源的项目，主要负责AOP的简化以及标准化，所以在使用SpringAOP的同时要支持AOP Allinance提供的接口，在老版本中Spring.jar里已经集成了，但是在Spring3.1.0中是没有的，需要引入aopalliance-1.0.jar。


使用ProxyFactoryBean
作为一个被通知者所通知的bean，他必须被代理的，Spring中的ProxyFactoryBean是一个工厂bean，用于生成一个代理，把一个或多个通知者应用到bean中。现在来修改一下要被通知的bean的id：

我把id从performer修改为performerTarget来表示这个bean是被通知者所通知的。下面为performerTarget创建一个代理：

下面来说下这三个属性：
Target属性引用的是被通知的bean
interceptorNames属性引用的是通知者
proxyInterfaces属性引用的是被通知的bean所实现的接口
下面来运行一下就能看到结果了：


下面在回过来看一下PerformerImpl类：

现在这个类变的非常的干净，没有再和Audience耦合再一起，就算交叉事务有改动也无序在去修改主业务逻辑的代码，是不是变的很方便。
抽象ProxyFactoryBean
现在我们只代理了一个bean：performerTarget，但是当另一个bean也需要被audienceAdvisor通知者所通知，那就意味着我们要创建一个新的代理，当程序中有成千上万的类等着被通知，那创建代理是不是会很麻烦，我们可以抽象的ProxyFactoryBean来解决这一问题首先把它变成一个抽象的代理，并且换了一个新的id：

然后声明一个id为performer来扩展audienceProxyBase：

这样就简单多了，如果有新的bean需要被通知，只需要扩展它就可以，不用在创建新的代理，而且可以进一步减少用通知者代理bean的xml。


自动代理
Performer和performerTarget总是令人迷惑的，而且也不便于规划，ProxyFactoryBean会使你的xml变的很繁琐，就算定义了抽象的ProxyFactoryBean让bean来扩展，也需要为每个被通知的bean声明两个bean：目标bean和代理bean。
我们可以使用DefaultAdvisorAutoProxyCreator，它会自动检查通知者的切点是否匹配bean。
只需要这么声明即可：

这个bean是没有id的，这是因为我们不会直接饮用它，spring会利用它创建代理。
这样就没有以target结尾的奇怪的名字了。



暂时还没找工作，不过也快了

Aop到此结束了，剩下的就是大家对aop的实际应用了，如果有一些更好的方法或功能，希望大家贴出来以供学习。