对于最新的稳定版本,请使用 Spring Framework 6.2.0! |
选择要使用的 AOP 声明样式
一旦您确定某个 aspect 是实现给定 需求,你如何决定是使用 Spring AOP 还是 AspectJ 以及 方面语言(代码)样式、@AspectJ 注释样式还是 Spring XML 样式?这些 决策受多种因素影响,包括应用程序要求、 开发工具,以及团队对 AOP 的熟悉程度。
Spring AOP 还是完整的 AspectJ?
使用最简单的方法。Spring AOP 比使用完整的 AspectJ 更简单,因为 不需要将 AspectJ 编译器/编织器引入到你的开发中 并构建流程。如果只需要在 Spring 上通知操作的执行 beans 中,Spring AOP 是正确的选择。如果您需要通知 不受 管理 的对象 Spring 容器(通常例如域对象)中,您需要使用 AspectJ 的如果你希望通知 join points 而不是 简单的方法执行(例如,字段 Get 或 Set 连接点等)。
当您使用 AspectJ 时,您可以选择 AspectJ 语言语法(也称为 “代码样式”)或@AspectJ注释样式。如果 aspect 播放 large 角色,并且您可以使用 AspectJ Development Tools (AJDT) 插件,AspectJ 语言语法是 首选选项。它更简洁、更简单,因为该语言是有意为之的 专为写作方面而设计。如果您不使用 Eclipse 或只有几个方面 在您的应用程序中没有主要作用,您可能需要考虑使用 @AspectJ样式,在 IDE 中坚持使用常规 Java 编译,并在 IDE 中添加 构建脚本的 aspect 编织阶段。
Spring AOP @AspectJ还是 XML?
如果您选择使用 Spring AOP,则可以选择 @AspectJ 或 XML 样式。 需要考虑各种权衡。
XML 样式对于现有的 Spring 用户来说可能是最熟悉的,并且它由真正的 POJO 的。当使用 AOP 作为配置企业服务的工具时,XML 可能是一个很好的 choice(一个很好的测试是,您是否认为 pointcut 表达式是 配置)。对于 XML 样式,它是 可以说,从您的配置中可以更清楚地了解系统中存在哪些方面。
XML 样式有两个缺点。首先,它没有完全封装 它在一个地方实现它所解决的需求。DRY 原则说 任何部分都应该有一个单一的、明确的、权威的表示 系统内的知识。使用 XML 样式时,了解需求如何 的实现被拆分到支持 Bean 类的声明和 XML 中 配置文件。当您使用 @AspectJ 样式时,此信息将被封装 在单个模块中:Aspect。其次,XML 样式在哪些方面稍受限制 它能表达的比@AspectJ风格:只有 “singleton” 方面实例化模型 ,并且无法组合在 XML 中声明的命名切入点。 例如,在 @AspectJ 样式中,您可以编写如下内容:
-
Java
-
Kotlin
@Pointcut("execution(* get*())")
public void propertyAccess() {}
@Pointcut("execution(com.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}
@Pointcut("execution(* get*())")
fun propertyAccess() {}
@Pointcut("execution(com.xyz.Account+ *(..))")
fun operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
fun accountPropertyAccess() {}
在 XML 样式中,您可以声明前两个切入点:
<aop:pointcut id="propertyAccess"
expression="execution(* get*())"/>
<aop:pointcut id="operationReturningAnAccount"
expression="execution(com.xyz.Account+ *(..))"/>
XML 方法的缺点是不能通过组合这些定义来定义切入点。accountPropertyAccess
@AspectJ 样式支持其他实例化模型和更丰富的切入点 组成。它的优点是将方面保持为模块化单元。它还具有 @AspectJ方面可以被理解(从而消费)的优势 Spring AOP 和 AspectJ.因此,如果您稍后决定需要 AspectJ 的功能 为了实现其他需求,您可以轻松地迁移到经典的 AspectJ 设置。 一般来说,Spring 团队更喜欢 @AspectJ 样式来自定义 aspects,而不仅仅是简单的 企业服务的配置。