扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作为这个介绍Spring框架中的面向方面编程(Aspect-Oriented Programming，AOP)的系列的第一部分，本文介绍了使您可以使用Spring中的面向方面特性进行快速开发的基础知识。使用跟踪和记录方面（面向方面领域的HelloWorld）作为例子，本文展示了如何使用Spring框架所独有的特性来声明切入点和通知以便应用方面。本系列的第二部分将更深入地介绍如何运用Spring中的所有通知类型和切入点来实现更实用的方面和面向方面设计模式。对于AOP的更一般性的介绍，请查看ONJava站点上Graham O'Regan的文章，“Introduction to Aspect-Oriented Programming”。
本文的目的不是要介绍构成模块化J2EE系统――即Spring框架――的所有重要元素，我们将只把注意力放在Spring所提供的AOP功能上。由于Spring的模块化设计方法，我们可以只使用该框架的AOP元素，而无需对构成Spring框架的其他模块做太多考虑。
在AOP方面，Spring提供了什么？
“它的目标不是提供最完善的AOP实现（虽然Spring AOP非常强大）；而是要提供AOP实现与Spring IoC的紧密集成，以便帮助解决企业应用中的常见问题。”
Spring Framework参考文档
为了实现这个目标，Spring框架目前支持一组AOP概念，从切入点到通知。本文将展示如何使用Spring框架中所实现的如下AOP概念：
通知（Advice）：如何将before通知、afterReturning通知和afterThrowing通知声明为bean。
切入点（Pointcut）：如何声明静态切入点逻辑以将XML Spring Bean Configuration文件中的所有内容联系在一起。
Advisor：关联切入点定义与通知bean的方式。
设置场景：一个简单的例子应用程序
“一般而言，Spring并不是预描述的。虽然使用好的实践非常容易，但是它避免强制推行一种特定的方法。”
Spring Framework参考文档
要试用Spring框架的AOP功能，首先我们要创建一个简单的Java应用程序。IbusinessLogic接口和BusinessLogic类为Spring框架中的bean提供了简易构件块。虽然该接口对于我们的简单应用程序逻辑来说不是必需的，但是它是Spring框架所推荐的良好实践。
public interface IBusinessLogic
{
public void foo();
}
public class BusinessLogic
implements IBusinessLogic
{
public void foo()
{
System.out.println(
"Inside BusinessLogic.foo()");
}
}
可以编写MainApplication类，借此练习BusinessLogic bean的公有方法。
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class MainApplication
{
public static void main(String [] args)
{
// Read the configuration file
ApplicationContext ctx =
new FileSystemXmlApplicationContext(
"springconfig.xml");
//Instantiate an object
IBusinessLogic testObject =
(IBusinessLogic) ctx.getBean("businesslogicbean");
// Execute the public
// method of the bean
testObject.foo();
}
}
在BusinessLogic类及其关联接口中没有什么需要注意的。但是，MainApplication类初始化BusinessLogic对象的方式很有意思。通过使用ctx.getBean("businesslogicbean")调用，MainApplication将加载和管理BusinessLogic类的bean实例的任务转交给了Spring框架。
允许Spring控制BusinessLogic bean的初始化，这使得Spring运行时有机会在bean被返回给应用程序之前执行J2EE系统所需的所有与bean相关的管理任务。然后Spring运行时配置可以决定对bean应用哪些任务和模块。该配置信息由一个XML文件提供，类似于下面所示的：
"-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
该配置文件，即springconfig.xml，指定要加载一个接口与IbusinessLogic相匹配的bean。该bean随后被关联到BusinessLogic实现类。看起来好像是费了很大力气只为了加载一个简单的bean并调用一个方法，但是您要知道，这个配置文件只是使Spring框架可以透明地对应用程序应用其组件的众多特性的一个体现。
图1显示了基本的顺序图：MainApplication原样执行，没有应用方面。
图1.没有对BusinessLogic bean应用方面时的顺序图
应用方法跟踪（Method Tracing）方面
可能最基本的方面就是方法跟踪方面了。这可能是您找得到的最简单的方面了，因此它是研究新的AOP实现的一个很好的起点。
方法跟踪方面在一个目标应用程序内捕获对所跟踪的方法的调用以及方法的返回值，并以某种方式显示这种信息。在AOP中，通知的before和after类型用于捕获这些类型的联结点，因为这两种通知可以在方法调用联结点之前或之后触发。使用Spring框架，方法跟踪方面的before通知是在TracingBeforeAdvice类中声明的。
import java.lang.reflect.Method;
import org.springframework.aop. MethodBeforeAdvice;
public class TracingBeforeAdvice
implements MethodBeforeAdvice
{
public void before(Method m,
Object[] args,
Object target)
throws Throwable
{
System.out.println(
"Hello world! (by " +
this.getClass().getName() +
")");
}
}
类似地，after通知可以在TracingAfterAdvice类中声明。
import java.lang.reflect.Method;
import org.springframework.aop.AfterReturningAdvice;
public class TracingAfterAdvice
implements AfterReturningAdvice
{
public void afterReturning(Object object,
Method m,
Object[] args,
Object target)
throws Throwable
{
System.out.println(
"Hello world! (by " +
this.getClass().getName() +
")");
}
}
这两个类都通过实现Spring框架的适当通知接口而表示了特定的通知。每种类型的通知都指定实现before(..)或afterReturning(..)方法，以便使Spring运行时可以告诉通知适当的联结点会在何时出现。值得注意的是，TracingAfterAdvice实际上是从AfterReturningAdvice扩展而来的，表示只有在联结点在无异常的情况下获得返回值时才运行通知。
为了将通知与应用程序中的适当联结点关联起来，必须对springconfig.xml进行一些修改。
"-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
theTracingBeforeAdvisor和theTracingAfterAdvisor advisor被添加到前面所声明的businesslogicbean。每个advisor都可能截获所有bean所关联到的联结点。Advisor本身就是bean，而它唯一的作用就是将切入点定义与通知bean关联起来。本例中的切入点定义是在静态对象层次结构中指定相关联结点的正则表达式。
因为本例中使用了org.springframework.aop.support.RegexpMethodPointcutAdvisor切入点advisor，切入点逻辑是使用正则表达式指定的。正则表达式用于识别公有接口对IbusinessLogici接口的联结点。下面是一些可以用来指定IBusinessLogic接口上的不同联结点集合的正则表达式例子：
springconfig.xml文件中最后的bean声明指定实现通知bean的类。
既然已经指定了跟踪方面的正确配置，那么下一次执行MainApplication时，这些方面就会在初始化过程中被编织进去，而BusinessLogic bean中的所有方法都将被跟踪，如图2所示。
图2. 方法跟踪方面应用到BusinessLogic bean之后的顺序图（单击图像查看大图）
方面的重用
可以对方法跟踪方面进行扩展，提供一个稍微复杂的记录（Logging）方面。记录方面提供了一个很不错的重用例子，因为记录方面所需的许多特性都已经包含在方法跟踪方面中了。
在本例中，记录方面扩展了方法跟踪方面，以便显示附加的与（在应用程序的执行过程中）所引发的异常有关的信息。
要完全使用记录方面，需要对应用程序做一些更改。BusinessLogicException异常类提供了一个可以由IBusinessLogicInterface接口和BusinessLogic实现类新增的void bar()方法引发的异常。
public class BusinessLogicException
extends Exception
{
}
public interface IBusinessLogic
{
public void foo();
public void bar()
throws BusinessLogicException;
}
public class BusinessLogic
implements IBusinessLogic
{
public void foo()
{
System.out.println(
"Inside BusinessLogic.foo()");
}
public void bar()
throws BusinessLogicException
{
System.out.println(
"Inside BusinessLogic.bar()");
throw new BusinessLogicException();
}
}
MainApplication类现在将对void bar()方法进行一次额外的调用，并处理选中的、可能由该方法引发的异常。
import org.springframeworkcontext.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class MainApplication
{
public static void main(String [] args)
{
// Read the configuration file
ApplicationContext ctx =
new FileSystemXmlApplicationContext(
"springconfig.xml");
//Instantiate an object
IBusinessLogic testObject =
(IBusinessLogic) ctx.getBean(
"businesslogicbean");
//Execute the public methods of the bean
testObject.foo();
try
{
testObject.bar();
}
catch(BusinessLogicException ble)
{
System.out.println(
"Caught BusinessLogicException");
}
}
}
来自方法跟踪方面的TracingBeforeAdvice和TracingAfterAdvice通知可以整体重用。LoggingThrowsAdvice类为新的异常记录提供了通知。
import org.springframework.aop.ThrowsAdvice;
import java.lang.reflect.Method;
public class LoggingThrowsAdvice
implements ThrowsAdvice
{
public void afterThrowing(Method method,
Object[] args,
Object target,
Throwable subclass)
{
System.out.println(
"Logging that a " +
subclass +
"Exception was thrown.");
}
}
应用记录方面的最后一步是修改springconfig.xml配置文件，使其包含新添加的LoggingThrowsAdvice通知。
图3显示了运行MainApplication并使用Spring框架应用了记录方面的UML顺序图。
图3. 记录方面应用到BusinessLogic bean之后的顺序图（单击图像查看大图）
此处的记录方面清楚地说明了如何重用现有方面以及如何在Spring框架中使用通知的throws形式。通过为before和after通知声明新的通知来重写现有的方法跟踪方面实现，可以实现更复杂的记录方面，记录到更复杂的记录框架，比如LOG4J。
结束语
本文展示了使用Spring框架中的基本AOP结构所应用的一些简单方面。在本系列的下一篇文章中，我们将介绍一些更实用的方面，探讨方面的生命周期，使用Spring框架的around通知，并使用Spring来应用AOP模式。
Spring Framework中的面向方面编程一
在本系列的第一部分，我介绍了如何实现面向方面领域的“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。
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类，如下所示：
public interface IBusinessLogic
{
public void foo();
}
public class BusinessLogic
implements IBusinessLogic
{
public void foo()
{
System.out.println(
"Inside BusinessLogic.foo()");
}
}
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class MainApplication
{
public static void main(String [] args)
{
// Read the configuration file
ApplicationContext ctx =
new FileSystemXmlApplicationContext(
"springconfig.xml");
//Instantiate an object
IBusinessLogic testObject =
(IBusinessLogic) ctx.getBean(
"businesslogicbean");
// Execute the public
// method of the bean
testObject.foo();
}
}
要对一个BusinessLogic类的实例彻底重写对foo()方法的调用，需要创建around通知，如下面的AroundAdvice类所示：
import org.aopalliance.intercept.MethodInvocation;
import org.aopalliance.intercept.MethodInterceptor;
public class AroundAdvice
implements MethodInterceptor
{
public Object invoke(
MethodInvocation invocation)
throws Throwable
{
System.out.println(
"Hello world! (by " +
this.getClass().getName() +
")");
return null;
}
}
要在Spring中用作around通知，AroundAdvice类必须实现MethodInterceptor接口和它的invoke(..)方法。每当截获到方法的重写，invoke(..)方法就会被调用。最后一步是改变包含在应用程序的springconfig.xml文件中的Spring运行时配置，以便可以对应用程序应用AroundAdvice。
"http://www.springframework.org/dtd/spring-beans.dtd">
根据该springconfig.xml配置文件，theAroundAdvisor截获所有对BusinessLogic类的方法的调用。接下来，theAroundAdvisor被关联到theAroundAdvice，表明当截获一个方法时，就应该使用在AroundAdvice类中指定的通知。既然已经指定了around通知的正确配置，下一次执行MainApplication类时，BusinessLogic bean的foo()方法就会被截获并重写，如图3所示：
图3. 使用around通知重写对BusinessLogic类中的foo()方法的调用
前面的例子显示，BusinessLogic类中的foo()方法可以通过AroundAdvice类中的invoke(..)方法彻底重写。原来的foo()方法完全不能被invoke(..)方法调用。如果希望从around通知内调用foo()方法，可以使用proceed()方法，可从invoke(..)方法的MethodInvocation参数中得到它。
public class AroundAdvice
implements MethodInterceptor
{
public Object invoke(
MethodInvocation invocation)
throws Throwable
{
System.out.println(
"Hello world! (by " +
this.getClass().getName() +
")");
invocation.proceed();
System.out.println("Goodbye! (by " +
this.getClass().getName() +
")");
return null;
}
}
图4显示了对proceed()的调用如何影响操作的顺序（与图3所示的初始around通知执行相比较）。
图4. 从around通知内使用proceed()调用原来的方法
当调用proceed()时，实际是在指示被截获的方法（在本例中是foo()方法）利用包含在MethodInvocation对象中的信息运行。您可以通过调用MethodInvocation类中的其他方法来改变该信息。
您可能希望更改包含在MethodInvocation类中的信息，以便在使用proceed()调用被截获的方法之前对被截获方法的参数设置新值。
通过对MethodInvocation对象调用getArguments()方法，然后在返回的数组中设置其中的一个参数对象，最初传递给被截获的方法的参数可以被更改。
如果IbusinessClass和BusinessLogic类的foo()方法被更改为使用整型参数，那么就可以将传递给被截获的调用的值由在AroundAdvice的notify(..)方法中传递改为在foo(int)中传递。
public class AroundAdvice
implements MethodInterceptor
{
public Object invoke(
MethodInvocation invocation)
throws Throwable
{
System.out.println(
"Hello world! (by " +
this.getClass().getName() +
")");
invocation.getArguments()[0] = new Integer(20);
invocation.proceed();
System.out.println(
"Goodbye! (by " +
this.getClass().getName() +
")");
return null;
}
}
在本例中，被截获的方法的第一个形参被假设为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()方法不是 该功能部件的一部分，所以不进行置换。
public interface IBusinessLogic
{
public void foo();
}
public interface IBusinessLogic2
{
public void bar();
public void baz();
}
此处，ReplacementFeature类扮演了“杜鹃的蛋”的角色，它提供了将被透明地引入应用程序的替代实现。ReplacementFeature类实现了所有在该类引入时要被置换的方法。
public class ReplacementFeature
{
public void foo()
{
System.out.println(
"Inside ReplacementFeature.foo()");
}
public void bar()
{
System.out.println(
"Inside ReplacementFeature.bar()");
}
}
现在需要声明一个around通知来截获对跨越bean的功能部件的方法调用。CuckoosEgg类提供了某种around通知来检查被截获的方法，并将适当的方法调用传递给ReplacementFeature类的实例。
public class CuckoosEgg implements MethodInterceptor
{
public ReplacementFeature replacementFeature =
new ReplacementFeature();
public Object invoke(MethodInvocation invocation)
throws Throwable
{
if (invocation.getMethod().getName().equals("foo"))
{
replacementFeature.foo();
}
else
{
replacementFeature.bar();
}
return null;
}
}
因为与Spring框架关系密切，Cuckoo's Egg设计的详细信息被放在springconfig.xml配置文件中。对springconfig.xml文件的更改将确保所有对IbusinessLogic和IBusinessLogic2 bean的foo()方法和bar()方法的调用都将被截获，并传递给CuckoosEgg类的around通知。
...
...
当使用修改后的springconfig.xml文件运行例子应用程序时，要替换的、被指定为功能部件的一部分的方法调用完全被截获并传递给ReplacementFeature类。
通常，即使在同一个实现环境中，我们也可以用不同的方法来实现同一种设计模式。实现上例的另一种方法是实现两个独立的通知。
最后需要注意的是，使用Cuckoo's Egg设计模式置换的功能部件，不管它是跨越bean的还是在一个类中，它的生命周期与它所置换的功能部件的目标生命周期匹配。在上例中这没什么问题，因为只有一个功能部件实例被置换了，而且唯一的Cuckoo's Egg通知只维护一个替代功能部件。
这个例子非常简单，而在实践中，您很可能必须处理大量需要用各自的Cuckoo's Egg实例置换的功能部件实例。在这种情况下，单个的方面实例需要被关联到单个的要置换的功能部件实例。本系列的下一篇文章将会考虑方面生命周期的用法，届时将解决这个问题。
结束语
本文介绍了如何在Spring框架内谨慎使用around形式的通知。around形式的通知常用于实现Cuckoo's Egg设计模式时，所以我们引入了一个例子来说明如何使用Spring AOP实现这种面向方面设计模式。
在本系列的第三部分中，您将看到如何使用Spring框架中其他的AOP基本概念。这些概念包括：控制方面生命周期、使用基于introduction通知的积极方面改变应用程序的静态结构，以及使用control flow切入点实现对方面编织的更细微的控制。
如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。
京公网安备 11010802021500号