Comparing Spring AOP and AspectJ

AOP 概念

在我们开始之前，让我们做一个快速、高级别审查的核心术语和概念：

方面 — —标准 / 特征代码被分散在多个场所中的应用，通常不同于实际的业务逻辑 (例如，交易管理) 。各方面集中于特定的切割功能
Joinpoint –它的具体执行过程中程序的执行等方法，调用构造函数或赋值域
建议采取的行动方面在特定 Joinpoint
切入点 — — Joinpoint 正则表达式来匹配的。每个时间点加入任何匹配的切入点，这个切入点建议相关规定执行
织造 – 的手续方面的针对性建议对象创建一个对象

Spring AOP 和 AspectJ

现在，让我们讨论一下 Spring AOP 和 AspectJ 的轴线 — — 诸如能力、目标、编织、内部结构、连接点和质朴。

能力和目标

简单来说， Spring AOP 和 AspectJ 有不同的目标。

SpringAOP 是 AOP 的简单实现 Spring IoC 来解决该问题，最常见的一类。它并不意图作为完整解决方案的 AOP- 它只能应用于被管理的 Bean 时， Spring 容器。

另一方面，AspectJ 是 AOP 技术的原始的 AOP 提供完整解决方案。它更为鲁棒，但是也明显多于 Spring AOP 。同时，值得注意的是，可以应用于所有的 AspectJ 域对象。

织造

Spring AOP 和 AspectJ 都使用了不同类型的编织行为有关，严重影响其性能和易用性。

AspectJ 利用三种不同类型的编织：

编译时编织AspectJ 编译器：输入源代码的应用方面我们和我们的生产和织造类文件作为输出
织造后编译这也被称为二进制编织。它是用于现有类文件和 JAR 文件，我们方面
装载时织入这正是：像原来的二进制编织，与编织的差，直至类加载器加载到 JVM 中的类文件

更深入的信息对 AspectJ 本身，看一下这篇文章。

作为使用 AspectJ 编译器 classload 织造时间和时间，利用 Spring AOP 的运行时编织。

与运行时编织，该编织方面在执行应用程序期间使用代理在目标物品 — — JDK 动态代理或使用代理 (在下面讨论的点) ：

内部结构和应用

Spring AOP 是一个基于代理的 AOP 框架。这意味着，为了实现这些方面的目标对象，它创建代理对象。这是通过使用以下两种方式：

JDK 的动态代理 AOP 方式优选为弹簧。即使当目标对象实现一个接口，然后使用 JDK 动态代理
CGLIB 代理 – 如果目标对象不实现接口，则代理可以使用

我们可以更深入地了解 Spring AOP 代理的机制官方文档。

AspectJ 中，另一方面，起不到任何作用，因为类在运行时被编译直接的方面。

Spring AOP 等不同，它不需要任何设计图案。在织造方面，介绍了其称为编译 AspectJ 编译器（ ajc ），编译和运行程序，然后通过小的 (< 100K).

连接点

在 3.3 节中，我们显示，基于代理的 Spring AOP 模式。正因为如此，它需要 Java 类和子类的对象将横切关注点应用。

但它具有局限性。我们不能将横切关注点应用类别 (或方面) 的 “最终” ，因为它们不能被重写，从而它将导致运行异常。

这同样适用于静态和最终方法。弹簧方面不能应用，因为它们不能被重写。因此，因为 Spring AOP 的这些限制，只支持方法执行连接点。

然而，AspectJ 编织将横切关注点直接转换成实际的代码之前运行。Spring AOP 不同，它不需要对象的子类对象，并因此支持许多其他的连接点。以下是对支持的连接点：

Joinpoint	Spring AOP 支持	AspectJ 支持
呼叫方法	没有	是的
执行方法	是的	是的
调用构造函数	没有	是的
执行构造函数	没有	是的
执行静态初始化器	没有	是的
对象初始化	没有	是的
参考场	没有	是的
外勤任务	没有	是的
执行处理程序	没有	是的
执行建议	没有	是的

值得注意的是在 spring aop 中，问题不是所谓的方法应用于同一类别。

这是因为，当我们调用在同一个类中定义的方法，则不调用该方法， Spring AOP 的代理提供。如果我们需要这个功能，那么我们必须定义一个不同的咖啡豆中分离方法，或者使用 AspectJ 。

简单

Spring AOP 是明显更简单，因为它不引入任何额外的编译器或编织器之间的编译过程。它使用运行时编织，因此我们通常无缝集成与构建过程。虽然它看上去很简单，它只通过弹簧托管 bean 。

然而，使用 AspectJ ，我们需要采用 AspectJ 编译器（ ajc ）和重新封装库（除非我们所有我们切换到编译后或装入时编织的情况下) 。

当然，比前者更复杂，因为它介绍了 AspectJ 工具 (包括 Java 编译器（ ajc ）、调试器 (ajdb ）、文件生成器 (ajdoc) 、浏览器程序 ajbrowser 结构 ()) ，我们需要集成或与 IDE 中的构建工具。

性能

就表演而言，编译时编织的运行时编织。Spring AOP 是一个基于代理的架构，使得代理的存在时启动应用。此外，还有几个方面每个方法调用，这影响了性能。

另一方面， AspectJ 中的方面编织到主代码在应用程序执行之前，没有额外的运行时开销，不像 Spring AOP 。

由于这些原因，基准AspectJ 是几乎认为大约 8 到 35 倍 Spring AOP 。

摘要

这个表快速汇总了主要差异, Spring AOP 和 AspectJ 之间进行：

Spring AOP	AspectJ
用纯 Java	使用 Java 编程语言的扩展
不需要单独的编码过程	需要 AspectJ 编译器（ ajc ）除非 LTW 设置
唯一可用的运行时编织	织造运行时不可用。支持编译，编译后，加载时织入
更强大 — — 只支持织制方法	更可编织更强大 — — 字段、方法、构造函数、静态初始化器，最终类 / 方法等 …
可以只针对 bean 的 Spring 容器管理	可以实现对所有域对象
仅支持执行切入点方法	所有支持的切入点
代理创建的目标对象，同时也应用在这些代理	方面的编织直接转换成代码之前执行应用程序 (在运行时之前)
AspectJ 慢得多	更好的性能
简单易学适用	相对更复杂的是 Spring AOP

选择合适的框架

如果我们在所有分析的论点，我们就会明白，这根本没有那么一个框架比另一种更好。

简单来说，在很大程度上取决于我们的选择要求：

框架：如果不使用 Spring 框架，然后我们就别无选择，只能放弃这个想法，因为它使用的是 Spring AOP 不能管理任何弹簧之外的容器。然而，如果我们应用全部创建使用 Spring 框架，然后我们可以使用 Spring AOP 的简单的学习和应用
灵活性： Joinpoint 有限的支持，是不完整的 Spring AOP 面向方面编程 (AOP) 的解决方案，但它解决了问题，最常见的一类。但如果我们想要更深入地挖掘和利用 AOP 以其最大能力的支持，希望从广泛可用的连接点，则是选择了 AspectJ
表现：如果我们使用有限的方面，则有轻微的性能差异。但有时会因申请以上几方面。我们不希望使用这种运行时编织的情况下，还是选择了 AspectJ 。AspectJ 是 8 至 35 倍 Spring AOP
最好的：这些框架的完全兼容。我们总是可以利用 Spring AOP 和 AspectJ 使用时仍可能得到支撑的连接点不支持由前任