基于Schema的AOP

基于Schema的AOP是Spring2.0发布之后新增加的一种AOP使用方式，我们可以从如下两个角度来看待基于Schema的AOP。

配置方式的改变。Spring框架从1x版本升级到2…x版本之后，提倡的容器配置方式从基于DTD的XML转向了基于Schema的XML，进一步提高了配置方式的灵活性和可扩展性。同时，新的基于Schema的配置方式为Spring的AOP功能专门提供了独有的命名空间。原来1.x中基于DTD的AOP配置方式，可以稍微转换一下配置方式就移植到基于Schema的AOP，所以，从这一点来说，基于Schema的AOP只是配置方式的改变。当然，这只是从本质上说，稍后我们将看到，还有少许新的AOP特性实际上是可用的。
@AspectJ形式AOP的折中。要使用@AspectJ形式的AOP，必须要求使用Java5或者更高版本的JDK或JRE，因为注解是Java5发布之后才引入的特性。如果我们不得不使用Java5之前的版本，而又想使用基于POJO的Aspect声明方式，这时，就可以使用基于Schema的SpringAOP。使用基于Schema的AOP，我们可以依然使用POJO声明Aspect以及相关的Advice。不过，不需要注解标注了，直接通过Shema的配置文件进行配置就可以，@AspectJ形式的Pointcut表达式也全都可以配置到基于Schema的配置文件中。

更多不做介绍，有兴趣可以看原文

本章小结

到目前为止，我们接触了如下三种SpringAOP的使用方式。

SpringAOP 1.x版本发布的 基于接口定义的Advice声明方式 。这种方式的特点是，各种类型的Advice定义需要实现特定的接口，Advice的管理可以通过IoC容器或者直接编程来进行。该方式从SpringAOP发布以来一直工作得很好，我们将称其为第一代SpringAOP。
@AspectJ形式 的AOP是在Spring2.0发布之后新增加的一种SpringAOP使用方式。在这种方式中，我们只需要 以POJO的形式声明相应的Aspect和Advice，然后通过相应的注解标注一下即可 。该方式的好处是，各种信息的管理统一到了一个位置，并且由于IDE的重构支持，AOP实现的管理更加方便高效。另外，只需要使用注解标注POJO中的Advice定义方法即可，而不用实现规定的接口来实现各种Advice类型。
基于Schema 的AOP也是在Spring2.0发布之后增加的SpringAOP使用方式。它融合了第一代SpringAOP和@AspectJ形式的AOP优点，不但完全支持第一代SpringAOP的配置需求，而且在@AspectJ形式的AOP的基础之上进行了改装：我们依然可以通过POJO声明Aspect和Advice定义。不过，通过相应注解表达的各种信息，转移到了XSD形式的容器配置文件中。

对于如何在这三种方式之间进行选择，应该依照当前应用环境、各种工具支持、整体团队对各种方式的熟悉程度等不同情况来权衡利弊，最终决定一种合适的方式。如果先抛开其他限制，要我选择的话，我会选择@AspectJ形式的AOP，原因为如下几点。

(1)Aspect和Advice的声明完全基于最普通的POJO。

(2)使用注解作为配置信息的载体，在当前IDE良好支持的大好前景下，重构不再是问题。

(3)AOP概念实体的声明和相关配置全部集中于一处管理，当你为了修改一点儿功能而要在多个文件之间“徜徉”的时候，就会发现将所有信息统一于一处管理的好处。

(4)强类型的方法参数声明，再也不用直接操作object[]，从而避免了信息的查找、对象的强制类型转换等琐事。

(5)通过Aspect将公用的Pointcut定义模块化管理。

随着2.x版本的SpringAOP发布，第一代SpringAOP好像可以退出历史舞台了。但实际上，它依然扮演着重要的角色。不要忘了， 在2.x版本的AOP中，不论是对AspectJ集成还是基于Schema的AOP的实现，最终的底层实现还是基于第一代SpringAOP的各种理念和实体。

虽然第一代SpringAOP不像2.x之后能够直接通过POJO声明Aspect和Advice，但是它的Advice实现依然拥有很强的表现力。在功能的实现方面，三种方式实际上是等效的。

至此，SpringAOP框架的相关讲解就算基本完成了。对于它的使用和实现原理，我想大家已经心中有数了。

下一章，我们关注使用AOP的一些最佳实践。