第7章使用Spring进行面向切面编程（AOP）

第 7 章 使用Spring进行面向切面编程（AOP）

目录

7.1. 简介

7.1.1. AOP概念

7.1.2. Spring AOP的功能和目标

7.1.3. Spring的AOP代理

7.2. @AspectJ支持

7.2.1. 启用@AspectJ支持

7.2.2. 声明一个切面

7.2.3. 声明一个切入点（pointcut）

7.2.4. 声明通知

7.2.5. 引入（Introductions）

7.2.6. 切面实例化模型

7.2.7. 例子

7.3. Schema-based AOP support

7.3.1. 声明一个切面

7.3.2. 声明一个切入点

7.3.3. 声明通知

7.3.4. 引入

7.3.5. 切面实例化模型

7.3.6. Advisors

7.3.7. 例子

7.4. 混合切面类型

7.5. 代理机制

7.6. 编程方式创建@AspectJ代理

7.7. 在Spring应用中使用AspectJ

7.7.1. 在Spring中使用AspectJ来为domain object进行依赖注入

7.7.2. Spring中其他的AspectJ切面

7.7.3. 使用Spring IoC来配置AspectJ的切面

7.7.4. 在Spring应用中使用AspectJ Load-time weaving（LTW）

7.8. 其它资源

7.1. 简介

面向切面编程（AOP）提供另外一种角度来思考程序结构，通过这种方式弥补了面向对象编程（OOP）的不足。 除了类（classes）以外，AOP提供了 切面。切面对关注点进行模块化，例如横切多个类型和对象的事务管理。 （这些关注点术语通常称作 横切（crosscutting） 关注点。）

Spring的一个关键的组件就是 AOP框架。 尽管如此，Spring IoC容器并不依赖于AOP，这意味着你可以自由选择是否使用AOP，AOP提供强大的中间件解决方案，这使得Spring IoC容器更加完善。

Spring 2.0 AOP

Spring 2.0 引入了一种更加简单并且更强大的方式来自定义切面，用户可以选择使用基于模式（schema-based）的方式或者使用@AspectJ注解。 对于新的应用程序，如果用户使用Java 5开发，我们推荐用户使用@AspectJ风格，否则可以使用基于模式的风格。 这两种风格都完全支持通知（Advice）类型和AspectJ的切入点语言，虽然实际上仍然使用Spring AOP进行织入（Weaving）。

本章主要讨论Spring 2.0对基于模式和基于@AspectJ的AOP支持。 Spring 2.0完全保留了对Spring 1.2的向下兼容性，下一章 将讨论Spring 1.2 API所提供的底层的AOP支持。

Spring中所使用的AOP：

• 提供声明式企业服务，特别是为了替代EJB声明式服务。 最重要的服务是 声明性事务管理（declarative transaction management） ， 这个服务建立在Spring的抽象事务管理（transaction abstraction）之上。

• 允许用户实现自定义的切面，用AOP来完善OOP的使用。

这样你可以把Spring AOP看作是对Spring的一种增强，它使得Spring可以不需要EJB就能提供声明式事务管理；或者也可以使用Spring AOP框架的全部功能来实现自定义的切面。

本章首先 介绍了AOP的概念，无论你打算采用哪种风格的切面声明，这个部分都值得你一读。 本章剩下的部分将着重于Spring 2.0对AOP的支持； 下一章 提供了关于Spring 1.2风格的AOP概述，也许你已经在其他书本，文章以及已有的应用程序中碰到过这种AOP风格。

如果你只打算使用通用的声明式服务或者预先打包的声明式中间件服务，例如缓冲池（pooling）， 那么你不必不直接使用Spring AOP，而本章的大部分内容也可以直接跳过。

7.1.1. AOP概念

首先让我们从定义一些重要的AOP概念开始。这些术语不是Spring特有的。 不幸的是，Spring术语并不是特别的直观；如果Spring使用自己的术语，将会变得更加令人困惑。

• 切面（Aspect）： 一个关注点的模块化，这个关注点可能会横切多个对象。事务管理是J2EE应用中一个关于横切关注点的很好的例子。 在Spring AOP中，切面可以使用通用类（基于模式的风格） 或者在普通类中以 @Aspect 注解（@AspectJ风格）来实现。

• 连接点（Joinpoint）： 在程序执行过程中某个特定的点，比如某方法调用的时候或者处理异常的时候。 在Spring AOP中，一个连接点 总是 代表一个方法的执行。 通过声明一个 org.aspectj.lang.JoinPoint 类型的参数可以使通知（Advice）的主体部分获得连接点信息。

• 通知（Advice）： 在切面的某个特定的连接点（Joinpoint）上执行的动作。通知有各种类型，其中包括“around”、“before”和“after”等通知。 通知的类型将在后面部分进行讨论。许多AOP框架，包括Spring，都是以拦截器做通知模型，并维护一个以连接点为中心的拦截器链。

• 切入点（Pointcut）： 匹配连接点（Joinpoint）的断言。通知和一个切入点表达式关联，并在满足这个切入点的连接点上运行（例如，当执行某个特定名称的方法时）。 切入点表达式如何和连接点匹配是AOP的核心：Spring缺省使用AspectJ切入点语法。

• 引入（Introduction）： （也被称为内部类型声明（inter-type declaration））。声明额外的方法或者某个类型的字段。 Spring允许引入新的接口（以及一个对应的实现）到任何被代理的对象。 例如，你可以使用一个引入来使bean实现 IsModified 接口，以便简化缓存机制。

• 目标对象（Target Object）： 被一个或者多个切面（aspect）所通知（advise）的对象。也有人把它叫做 被通知（advised） 对象。 既然Spring AOP是通过运行时代理实现的，这个对象永远是一个 被代理（proxied） 对象。

• AOP代理（AOP Proxy）： AOP框架创建的对象，用来实现切面契约（aspect contract）（包括通知方法执行等功能）。 在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。 注意：Spring 2.0最新引入的基于模式（schema-based）风格和@AspectJ注解风格的切面声明，对于使用这些风格的用户来说，代理的创建是透明的。

• 织入（Weaving）： 把切面（aspect）连接到其它的应用程序类型或者对象上，并创建一个被通知（advised）的对象。 这些可以在编译时（例如使用AspectJ编译器），类加载时和运行时完成。 Spring和其他纯Java AOP框架一样，在运行时完成织入。

通知的类型：

• 前置通知（Before advice）： 在某连接点（join point）之前执行的通知，但这个通知不能阻止连接点前的执行（除非它抛出一个异常）。

• 返回后通知（After returning advice）： 在某连接点（join point）正常完成后执行的通知：例如，一个方法没有抛出任何异常，正常返回。

• 抛出异常后通知（After throwing advice）： 在方法抛出异常退出时执行的通知。

• 后通知（After (finally) advice）： 当某连接点退出的时候执行的通知（不论是正常返回还是异常退出）。

• 环绕通知（Around Advice）： 包围一个连接点（join point）的通知，如方法调用。这是最强大的一种通知类型。 环绕通知可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。

环绕通知是最常用的一种通知类型。大部分基于拦截的AOP框架，例如Nanning和JBoss4，都只提供环绕通知。

跟AspectJ一样，Spring提供所有类型的通知，我们推荐你使用尽量简单的通知类型来实现需要的功能。 例如，如果你只是需要用一个方法的返回值来更新缓存，虽然使用环绕通知也能完成同样的事情， 但是你最好使用After returning通知而不是环绕通知。 用最合适的通知类型可以使得编程模型变得简单，并且能够避免很多潜在的错误。 比如，你不需要调用 JoinPoint（用于Around Advice）的 proceed() 方法，就不会有调用的问题。

在Spring 2.0中，所有的通知参数都是静态类型，因此你可以使用合适的类型（例如一个方法执行后的返回值类型）作为通知的参数而不是使用一个对象数组。

切入点（pointcut）和连接点（join point）匹配的概念是AOP的关键，这使得AOP不同于其它仅仅提供拦截功能的旧技术。 切入点使得定位通知（advice）可独立于OO层次。 例如，一个提供声明式事务管理的around通知可以被应用到一组横跨多个对象中的方法上（例如服务层的所有业务操作）。

7.1.2. Spring AOP的功能和目标

Spring AOP用纯Java实现。它不需要专门的编译过程。Spring AOP不需要控制类装载器层次，因此它适用于J2EE web容器或应用服务器。

Spring目前仅支持使用方法调用作为连接点（join point）（在Spring bean上通知方法的执行）。 虽然可以在不影响到Spring AOP核心API的情况下加入对成员变量拦截器支持，但Spring并没有实现成员变量拦截器。 如果你需要把对成员变量的访问和更新也作为通知的连接点，可以考虑其它语法的Java语言，例如AspectJ。

Spring实现AOP的方法跟其他的框架不同。Spring并不是要尝试提供最完整的AOP实现（尽管Spring AOP有这个能力）， 相反的，它其实侧重于提供一种AOP实现和Spring IoC容器的整合，用于帮助解决在企业级开发中的常见问题。

因此，Spring AOP通常都和Spring IoC容器一起使用。 Aspect使用普通的bean定义语法（尽管Spring提供了强大的“自动代理（autoproxying）”功能）： 与其他AOP实现相比这是一个显着的区别。有些事使用Spring AOP是无法轻松或者高效的完成的，比如说通知一个细粒度的对象。 这种时候，使用AspectJ是最好的选择。不过经验告诉我们： 于大多数在J2EE应用中遇到的问题，只要适合AOP来解决的，Spring AOP都没有问题，Spring AOP提供了一个非常好的解决方案。

Spring AOP从来没有打算通过提供一种全面的AOP解决方案来取代AspectJ。 我们相信无论是基于代理（proxy-based ）的框架比如说Spring亦或是full-blown的框架比如说是AspectJ都是很有价值的，他们之间的关系应该是互补而不是竞争的关系。 Spring 2.0可以无缝的整合Spring AOP，IoC 和AspectJ，使得所有的AOP应用完全融入基于Spring的应用体系。 这样的集成不会影响Spring AOP API或者AOP Alliance API；Spring AOP保留了向下兼容性。接下来的一章会详细讨论Spring AOP API。

7.1.3. Spring的AOP代理

Spring缺省使用J2SE 动态代理（dynamic proxies）来作为AOP的代理。这样任何接口都可以被代理。

Spring也支持使用CGLIB代理. 对于需要代理类而不是代理接口的时候CGLIB代理是很有必要的。 如果一个业务对象并没有实现一个接口，默认就会使用CGLIB。 此外，面向接口编程 也是一个最佳实践，业务对象通常都会实现一个或多个接口。

此外，还可以强制的使用CGLIB：我们将会在以后讨论这个问题，解释问什么你会要这么做。

在Spring 2.0之后，Spring可能会提供多种其他类型的AOP代理，包括了完整的生成类。这不会影响到编程模型。