Spring Framework中的面向方面编程（AOP），第二部分

在本系列的第一部分，我介绍了如何实现面向方面领域的“HelloWorld”：跟踪和记录方面。利用Spring框架所提供的面向方面编程(Aspect-Oriented Programming，AOP)功能，您看到了如何使用before-、after-和基于异常的通知，以及如何使用基于正则表达式的简单切入点。跟踪和记录方面提供了非常不错的上手例子，而本文将进一步介绍一种新的通知形式：around通知。

　　比起第一部分中介绍的那些通知类型，around形式的通知是一种更具侵入性也更强大的面向对象概念。本文将描述around通知的每个特性，以便您可以在自己的Spring AOP应用程序中正确地使用它。在本文最后，我将向您展示如何使用around通知来截获和改变应用程序中各个特性相互作用的方式，以便实现Cuckoo's Egg（杜鹃的蛋）面向方面设计模式。概述Spring AOP、IoC和代理
　　在第一部分，我们快速浏览了Spring的一些AOP特性，而没有阐明Spring如何实现AOP的细节。要理解Spring框架如何运转，尤其是它如何实现其AOP功能，首先您要明白，Spring是一个依赖于控制反转(Inversion of Control，IoC)设计模式的轻量级框架。　　注意：本文的目的不是要深入介绍IoC模式，介绍IoC只是为了使您明白该设计模式是如何影响Spring AOP实现的。有关IoC模式的更详细的介绍请参见本文末尾的参考资料。　　IoC设计模式的出现已经有一段时间了。一个最明显的例子就是J2EE架构本身。随着企业开发尤其是J2EE平台的出现，应用程序开始依赖于由外部容器所提供的一些特性，比如bean创建、持久性、消息传递、会话以及事务管理。　　IoC引入了一个新概念：由组件构成的框架，它与J2EE容器有许多类似之处。IoC框架分离了组件所依赖的功能，并且，根据Sam Newman文章中的说法，提供了“连接组件的‘胶水’”。　　对组件所依赖特性的控制 被反转 了，这样外部框架就可以尽可能透明地提供这些特性了。IoC模式真正意识到了从传统的由依赖于功能的组件来负责这些功能，到由独立的框架来配置和提供这些功能的方式转变。　　图1显示了一些构成IoC模式的不同组件角色的例子。
图1. 没有对BusinessLogic bean应用方面时的顺序图.　　图字：　　Component：组件　　Provides Facilities：提供功能　　Relies on and conforms to：依赖于并服从　　Manages the services the framework can then use to provide facilities：管理框架随后可以用来提供功能的服务　　Service：服务　　Your Component：您的组件　　IoC Framework：IoC框架　　External services：外部服务　　IoC模式使用3种不同的方法来解除组件与服务控制的耦合：类型1、类型2和类型3。类型1：接口注入
这是大部分J2EE实现所使用的方法。组件显式地服从于一组接口，带有关联的配置元数据，以便允许框架对它们进行正确的管理。 类型2：Setter注入
外部元数据被用来配置组件相互作用的方式。在第一部分中，我们就是使用这种IoC方法利用springconfig.xml文件来配置Spring组件的。 类型3：构造函数注入
组件（包括构造组件时要用的参数）注册到框架，而框架提供组件的实例以及所有要应用的指定功能。 　　IoC在组件开发和企业开发中越来越受欢迎。IoC的实际例子包括传统的J2EE解决方案，比如：JBoss、Apache基金会的Avalon项目以及本文的Spring框架。实际上，Spring框架构建于IoC模式的基础上是为了帮助将它的轻量级功能注入到它的相关应用程序的组件中。　　那么IoC对于Spring AOP有何意义呢？Spring的IoC特性是使用IoC springconfig.xml配置文件对应用程序应用方面的推动因素之一。springconfig.xml配置文件通知Spring框架运行时有关应用程序的组件要被注入的功能类型的信息，所以自然轻量级的AOP功能就以同样的方式应用了。然后Spring使用代理模式围绕现有的类和bean实现指定的AOP功能。　　图2显示了Spring及其IoC框架如何使用代理对象提供AOP功能（根据springconfig.xml文件中的IoC配置。）
图2. springconfig.xml配置文件改变了Spring框架IoC，以便随后向第一部分中的一个顺序图提供AOP代理（单击图像查看大图）　　在本系列下面的部分，您将不断看到现在包含在顺序图中的代理对象。这只是为了说明对于Spring AOP来说没有“魔法”，实际上只有一个面向对象设计模式的良好例子。回到AOP：使用around通知的积极方面
　　在第一部分，您看到了如何使用Spring AOP来实现跟踪和记录方面。跟踪和记录都是“消极”方面，因为它们的出现并不会对应用程序的其他行为产生影响。它们都使用了消极的before和after形式的通知。　　但是如果您希望改变应用程序的常规行为呢？例如说，您希望重写一个方法？这样的话，您就需要使用更积极的around形式的通知。　　第一部分的简单例子应用程序包括IbusinessLogic接口、BusinessLogic类和MainApplication类，如下所示：

　　要在Spring中用作around通知，AroundAdvice类必须实现MethodInterceptor接口和它的invoke(..)方法。每当截获到方法的重写，invoke(..)方法就会被调用。最后一步是改变包含在应用程序的springconfig.xml文件中的Spring运行时配置，以便可以对应用程序应用AroundAdvice。

图3. 使用around通知重写对BusinessLogic类中的foo()方法的调用　　前面的例子显示，BusinessLogic类中的foo()方法可以通过AroundAdvice类中的invoke(..)方法彻底重写。原来的foo()方法完全不能被invoke(..)方法调用。如果希望从around通知内调用foo()方法，可以使用proceed()方法，可从invoke(..)方法的MethodInvocation参数中得到它。
　　图4显示了对proceed()的调用如何影响操作的顺序（与图3所示的初始around通知执行相比较）。
图4. 从around通知内使用proceed()调用原来的方法　　当调用proceed()时，实际是在指示被截获的方法（在本例中是foo()方法）利用包含在MethodInvocation对象中的信息运行。您可以通过调用MethodInvocation类中的其他方法来改变该信息。　　您可能希望更改包含在MethodInvocation类中的信息，以便在使用proceed()调用被截获的方法之前对被截获方法的参数设置新值。　　通过对MethodInvocation对象调用getArguments()方法，然后在返回的数组中设置其中的一个参数对象，最初传递给被截获的方法的参数可以被更改。　　如果IbusinessClass和BusinessLogic类的foo()方法被更改为使用整型参数，那么就可以将传递给被截获的调用的值由在AroundAdvice的notify(..)方法中传递改为在foo(int)中传递。
　　在本例中，被截获的方法的第一个形参被假设为int。实参本身是作为对象传递的，所以通过将其包装在Integer类实例中的方法，基本的int类型的形参被改为对应数组中的新值。如果您将该参数设置为一个非Integer对象的值，那么在运行时就会抛出IllegalArgumentException异常。　　您还将注意到，invoke(..)方法必须包含一个return语句，因为该方法需要返回值。但是，被重写的foo()方法并不返回对象，所以invoke(..)方法可以以返回null结束。如果在foo()方法不需要的情况下，您仍然返回了一个对象，那么该对象将被忽略。　　如果foo()方法确实需要返回值，那么需要返回一个与foo()方法的初始返回类型在同一个类或其子类中的对象。如果foo()方法返回一个简单类型，例如，一个integer，那么您需要返回一个Integer类的对象，当方法被重写时，该对象会自动由AOP代理拆箱，如图5所示：
图5. around通知的装箱和自动拆箱　　图字：　　Object invoke：对象调用　　The integer return value is boxed in a Integer object in the AroundAdvice and then unboxed by the AOP Proxy：整型返回值被装箱在AroundAdvic通知的一个Integer对象中，然后由AOP代理拆箱。　　面向方面编程还是一个比较新的领域，尤其是与衍生出它的面向对象编程相比。设计模式通常被认为是常见问题的通用解决方案，因为面向方面发展的时间还不长，所以已发现的面向方面设计模式比较少。　　此处要介绍的是一种正在浮现的模式，即Cuckoo's Egg设计模式。该模式还有其他的叫法，它在面向对象领域的对等体包括模仿对象（Mock Object）和模仿测试（Mock Testing），甚至代理模式也与它有一些类似之处。　　Cuckoo's Egg面向方面设计模式可以被定义为应用程序上下文中功能部件的透明和模块化的置换。就像杜鹃偷偷地把自己的蛋放在另一种鸟的巢中一样，Cuckoo's Egg设计模式用一个替代功能部件实现置换现有的功能部件,而使造成的干扰尽可能少。　　这种置换的实现方式可以是静态的、动态的、部分的、完全的，针对一个对象的多个部分，或针对多个组件。使用面向方面的方法可以透明地实现功能部件的置换，而无需对应用程序的其余部分进行更改。要置换应用程序中现有功能部件的替代功能部件就是“杜鹃的蛋”。图6显示了Cuckoo's Egg设计模式中的主要组成元素。
图6. Cuckoo's Egg设计模式中的主要组成元素　　图字：　　Application：应用程序　　Component：组件　　Replacement Feature：替代功能部件　　Component 1 and 2 together encompass a distinct feature of the software：组件1和2共同包含了软件的一个独立的功能部件　　The Cuckoo's Egg pattern transparently replaces an existing feature of the software：Cuckoo's Egg模式透明地置换了软件现有的功能部件　　Before the pattern is applied：应用该模式前　　After the pattern is applied：应用该模式后　　Cuckoo's Egg设计模式依赖于around通知的概念。您需要借助于积极的和侵入性的around通知来截获并有效置换应用程序中现有的功能部件。　　有关Cuckoo's Egg设计模式的更多信息，以及AspectJ中的一个可选实现，请参见《AspectJ Cookbook》（O'Reilly，2004年12月出版）。　　要使用Spring AOP实现Cuckoo's Egg设计模式，需要声明一个around通知来截获所有对要置换的功能部件的调用。与hot-swappable target sources（Spring AOP的一个功能部件，将在本系列的另一篇文章中介绍）不同，around通知的显式使用使得Cuckoo's Egg实现可以有效地跨越对象边界（因此也可以跨越bean边界）进行整个功能部件的置换，如图7所示。
图7. 一个跨越bean边界的组件　　图字：　　A feature crosses the boundaries of BusinessLogic and BusinessLogic2 by depending on behavior supplied separately by the two beans：一个功能部件通过依赖于由BusinessLogic和BusinessLogic2各自提供的行为而跨越了这两个bean的边界　　下面的代码显示了一个具有两个bean的简单应用程序，其中有一个功能部件跨越了该应用程序的多个方面。要置换的功能部件可以被视为包含IBusinessLogic bean中的foo()方法和IBusinessLogic2 bean中的bar()方法。IBusinessLogic2 bean中的baz()方法不是 该功能部件的一部分，所以不进行置换。
?作者简介Russell Miles是General Dynamics UK公司的一名软件工程师，他负责Java和分布式系统，但是他目前主要的兴趣在面向方面领域，尤其是AspectJ。