Spring2.5.6中面向切面编程及实现的示例分析

本期，边肖将为大家带来Spring2.5.6中面向节的编程和实现的实例分析，文章内容丰富，从专业角度进行分析和叙述。看完这篇文章，希望你能有所收获。

面向方面编程通过提供另一种思考程序结构的方式，弥补了面向对象编程的不足。在面向对象程序设计中，模块化的关键单元是类，而在面向对象程序设计中，模块化单元是片。方面可以模块化关注点，例如横切多种类型和对象的事务管理。(在AOP术语中，它通常被称为横切关注点。)AOP框架是Spring的重要组成部分。但是Spring IoC容器并不依赖于AOP，这意味着你有权选择是否使用AOP。作为Spring IoC容器的补充，AOP使其成为一个强大的中间件解决方案。

Spring框架中AOP的作用是提供声明性的企业服务，尤其是替代EJB声明性服务。最重要的服务是声明性事务管理。允许用户实现定制的切割平面，并使用面向对象程序来改进面向对象程序的使用。在业务系统中，总有一些与业务逻辑无关的服务逻辑(如：日志、安全验证、事务管理等)。).

在传统的编程方法中，这些服务逻辑的代码总是渗透到业务逻辑的代码中，使得服务逻辑和业务逻辑的完成完全混合在一起，这将使业务系统更加复杂，不适合目前大规模业务系统的开放。图片：

图为传统编程模式下服务逻辑与业务逻辑的交织。

引入AOP后，这些服务逻辑被收集并设计成独立的可重用部分，这些部分可以编织在需要服务的业务逻辑之上。这样，这些服务逻辑可以灵活地应用于业务系统，并且在调用业务逻辑代码时不会受到关注。如图。

图：引入AOP后服务逻辑和业务逻辑的分离。

要理解AOP，我们必须首先理解AOP的几个术语：

l方面：

关注点的模块化，这可能会跨多个对象。事务管理是J2EE应用程序中横切关注点的一个很好的例子。在Spring AOP中，方面可以通过基于模式或@Aspect注释的方式来实现。

l连接点：

在程序执行的特定时刻，如调用方法或处理异常时。在Spring AOP中，连接点总是代表方法的执行。

l建议：

在切片的特定连接点上执行的操作。它包括不同类型的通知，如“周围”、“之前”和“之后”(通知的类型将在后面讨论)。许多AOP框架(包括Spring)使用拦截器作为通知模型，并维护一个以连接点为中心的拦截器链。

l切入点：

匹配连接点的断言。通知切入点表达式，并在满足该切入点的连接点上运行它(例如，当执行具有特定名称的方法时)。表达式如何匹配连接点是AOP的核心：默认情况下，Spring使用AspectJ切入点语法。

l导言：

用于向类型声明其他方法或属性(也称为类型间声明)。Spring允许向任何代理对象引入新的接口(和相应的实现)。例如，您可以使用import使bean实现IsModified接口，从而简化缓存机制。

目标对象(目标对象):

由一个或多个切片通知的对象。也称为建议对象。由于Spring AOP是通过运行时代理实现的，因此这个对象将始终是一个代理对象。

AOP代理(AOP代理):

由AOP框架创建的对象，用于实现切片契约(如通知方法执行等)。).在Spring中，AOP代理可以是JDK动态代理，也可以是CGLIB代理。

l编织(编织):

将该部分连接到其他应用程序类型或对象，并创建一个通知对象。这可以在编译时(例如，使用AspectJ编译器)、类加载时和运行时完成。像其他纯Java AOP框架一样，Spring在运行时完成编织。

声明：

通知类型：

在通知之前：在连接点之前执行的通知，但该通知不能阻止连接点之前的执行过程(除非它引发异常)。

返回建议后：连接点正常完成后执行的通知：例如，一个方法正常返回，没有抛出任何异常。

抛出建议后：当方法抛出异常并退出时要执行的通知。

后(最后)建议：当某个连接点后退时。

出的时候执行的通知(不论是正常返回还是异常退出)。

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

通过切入点匹配连接点的概念是AOP的关键，这使得AOP不同于其它仅仅提供拦截功能的旧技术。 切入点使得通知可以独立对应到面向对象的层次结构中。例如，一个提供声明式事务管理 的环绕通知可以被应用到一组横跨多个对象的方法上(例如服务层的所有业务操作)。

Spring AOP 实现

在Spring2.5.6中，常用的AOP实现的两种方法：

***种，是基于xml配置文件方式的实现。

第二种，是基于注解方式实现的。

那么Spring AOP中使用@AspectJ(注解)还是XML?他们没有没有个子的优缺点?

如果你不是运行 在Java 5上，XML风格是***选择。对于使用Java 5的项目，需要考虑多方面的折衷。

XML风格对现有的Spring用户来说更加习惯。它可以使用在任何Java级别中 (参考连接点表达式内部的命名连接点，虽然它也需要Java 5+) 并且通过纯粹的POJO来支持。当使用AOP作为工具来配置企业服务时XML会是一个很好的选择。 (一个好的例子是当你认为连接点表达式是你的配置中的一部分时，你可能想单独更改它) 对于XML风格，从你的配置中可以清晰的表明在系统中存在那些切面。

XML风格有两个缺点。

***是 它不能完全将需求实现的地方封装到一个位置。 DRY原则中说系统中的每一项知识都必须具有单一、无歧义、权威的表示。 当使用XML风格时，如何实现一个需求的知识被分割到支撑类的声明中以及XML配置文件中。 当使用@AspectJ风格时就只有一个单独的模块 -切面- 信息被封装了起来。

第二是 XML风格同@AspectJ风格所能表达的内容相比有更多的限制：仅仅支持"singleton"切面实例模型， 并且不能在XML中组合命名连接点的声明。例如，在@AspectJ风格中我们可以编写如下的内容：

Xml代码

@Pointcut(execution(* get*()))                        public void propertyAccess() {}                                        @Pointcut(execution(org.xyz.Account+ *(..))                        public void operationReturningAnAccount() {}                                        @Pointcut(propertyAccess() && operationReturningAnAccount())                    public void accountPropertyAccess() {}

在XML风格中能声明开头的两个连接点：

Xml代码

expression="execution(org.xyz.Account+ *(..))"/>

expression="execution(org.xyz.Account+ *(..))"/>

但是不能通过组合这些来定义accountPropertyAccess连接点

@AspectJ风格支持其它的实例模型以及更丰富的连接点组合。它具有将切面保持为一个模块单元的优点。 还有一个优点就是@AspectJ切面能被Spring AOP和AspectJ两者都理解 - 所以如果稍后你认为你需要AspectJ的能力去实现附加的需求，那么你非常容易迁移到基于AspectJ的途径。 总而言之，我们更喜欢@AspectJ风格只要你有切面去做超出简单的“配置”企业服务之外的事情。

结束语

我们完全可以混合使用以下几种风格的切面定义：使用自动代理的@AspectJ风格的切面， schema-defined 的切面，和用 声明的advisor，甚至是使用Spring 1.2风格的代理和拦截器。 由于以上几种风格的切面定义的都使用了相同的底层机制，因此可以很好的共存。

上述就是小编为大家分享的Spring2.5.6中面向切面编程及实现的示例分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。