开发环境
Mik Kersten （beatmik@cs.ubc.ca）
AOP 工具构建师、咨询顾问, University of British Columbia
2005 年 3 月
 在这个由两部分构成的 AOP 工具比较的第 2 部分中，面向方面专家 Mik Kersten 将把重点放在工具与开发环境的集成以及构建过程上，包括对 AOP 工具 IDE 特性的逐点比较。为了帮助制定最终决策，在进行总结的时候，作者将介绍这些快速发展的工具近期的发展情况，并提供每种工具优缺点的总结。注意，本文将解释最近宣布的 AspectJ 和 AspectWerkz 项目合并的意义。
在这个由两部分构成的 AOP 工具比较的第 1 部分 中，介绍了 4 种领先的 AOP 工具（AspectJ、AspectWerkz、JBoss AOP、Spring AOP）实现核心 AOP 机制的方式。虽然这些工具已经集中在连接点模型、切入点、通知和类型间声明的思想上，但是每种工具在处理 AOP 语法时，仍有各自明显的优缺点。正如在第 1 部分介绍的，语法的决策不仅影响方面编程时的感觉 —— 繁琐的语法 VS 更加直接、作为代码的切入点 VS 注释、通知保存在相同的源文件中 VS 本地化为 XML 中的方面配置 —— 而且还会对语义带来差异。现在，这一部分将继续探索不同技术的意义，但这次的重点是研究以上决策对 AOP 工具在整体开发过程和开发环境中的集成有什么影响。
本文从深入研究 AspectJ 对 Java™ 语言扩展的发展情况开始，重点查看代码风格在方面构建和静态检查方面的优势和不足。然后讨论每种工具的不同编译方式，并用最新的 AWBench 测评结果说明它们对性能的影响。
在 AOP 工具比较的第 2 部分中，最重要的讨论主题可能是 IDE 支持。本文将对每种工具的 IDE 支持逐个特性地进行比较，并对两个实际的 IDE 插件进行看得见的比较。本文还会介绍每种工具的文档和库支持情况，这两者是选择新技术实现时的重要因素。
文章结尾提供了对这些工具未来发展方向的一些推测，概括了每种工具的核心优势与不足。表 1 总结了整篇文章详细讨论的开发环境集成的一些关键因素。
表 1. AOP 工具比较：开发环境集成
|
关于本系列
AOP@Work 系列面对的是那些在面向方面编程上有些基础，并且想扩展或加深了解的开发人员（有关 AOP 的背景，请参阅参考资料）。同 developerWorks 的大多数文章一样，本系列的文章非常实用：读完每篇介绍新技术的文章，都可以立即将该技术投入实用。
本系列文章所选择的每位作者，都在面向方面编程领域内处于领先地位，或者具有这方面的专家水准。许多作者都是本系列文章中介绍的项目和工具的参与者。每篇文章都力图提供一个中立的评述，以确保这里所表达观点的公正性与正确性。
请分别就这些文章的评论或问题与它们的作者联系。要对本系列进行整体评论，可以与连载的负责人 Nicholas Lesiecki 联系。
关于本文
本文并不想突出某一种工具，而是想用一种批判的、没有偏见的方式突出每种工具的优势与不足。虽然作者是 AspectJ 项目的参与者之一，但是在编写本文的时候，也咨询了其他 AOP 工具项目的领导人，以确保公平地展示所讨论的技术。 |
如果读者已经读过第 1 部分，那么现在可能正想进行开发环境集成。
构建方面
在使用 AOP 工具时，不管是使用工具的 IDE 支持，还是通过 Ant 和命令行进行构建，您会注意到的第一件事是：AOP 工具与构建环境集成得怎么样？在谈到构建环境集成的时候，AOP 工具之间的关键区别在于该工具是否采用了语言扩展。虽然 AspectJ 提供了一种代码风格，这种风格是 Java 语言的一种扩展，但是其他三种技术都采用了普通 Java 语言与基于 XML 和注释的方面语言的组合。从集成的观点来看，AspectJ 对 Java 语言的扩展更有利，因为方面声明拥有与类声明一样简洁的格式和易于编辑的方式。但从负面来看，扩展 Java 语言是个挑战，因为每种解析 Java 源代码的工具都必须扩展，才能理解方面。结果，虽然目前有一套 AspectJ 工具（正如在特性比较中讨论的），但这个套件仍不完整。
从构建环境的角度看，这些技术的主要区别是：AspectJ 必须提供自己的编译器，而其他工具可以依靠标准的 Java 编译器。AspectJ 编译器扩展了 Eclipse Java 编译器，可以脱离 Eclipse 在命令行上独立运行，也可以用作 Eclipse 和其他 IDE 的插件。AspectJ 编译器对 “.java” 或 “.aj” 文件中声明的 AspectJ 和 Java 代码进行构建，并生成普通的 Java 字节码。虽然要使用新编译器这点有些不足，但是这么做可以提供切入点的静态检查，而且还会带来很大的益处。
切入点的静态检查
在处理类时，Java 程序员对静态检查的依赖很重。这意味着，不用过多考虑方法名称的拼写错误，因为编译器能够立即指出这类错误。如果没有进行静态检查，那么这类错误到了运行的时候才会被捕获。AspectJ 对于所有的方面声明都有完整的静态检查，所以 AspectJ 编译器会立即指出切入点中拼写错误的引用。其他 AOP 工具可以检查方面声明的合格程度，但是，不管是用注释还是用 XML 声明，它们都没有提供切入点的静态检查。对于典型的 Java 开发人员来说，这样做的后果是要投入大量精力查看 XML 值，而且还会在运行时带来大量调试错误。如果切入点中放错一个括号，那么不会显示容易修改的编译错误，只会造成很难阅读和调试的运行时堆栈跟踪。
有了 AspectJ 编译器，方面代码就可以得到 Java 代码从静态检查得到的全部好处。如果没有该编译器，那么在键入切入点表达式时，必须非常小心，而且还要适应通过执行应用程序找出错误，因为切入点的表达式非常复杂，所以这很容易带来问题。
在图 1 中可以看到两种工具处理切入点中括号错误的区别。图的上面显示了 AspectJ 中错误的出现方式，图的下面显示了 AspectWerkz 中错误的出现方式。
图 1. 在 AspectJ 中和在 AspectWerkz 中定位语法错误的比较
AspectJ 的编译器在键入代码的时候就会主动解析方面代码，立即指出括号错误。使用 AspectWerkz，则要到运行时才会检查出这个错误。由此可以看到，在没有切入点静态检查的工具中，这类语法错误需要更多时间调试。但是，更常见、更费时的问题则是因为在切入点中拼写出错误类型名这类的错误造成的。在没有进行静态检查的情况下，AOP 框架无法调用任何通知，因此会悄无声息地失败。指出错误在哪特别费时，尤其在初次接触 AOP 和切入点时。有了静态检查，AspectJ 的编译器会发出警告，指出无法解析的类型名称或签名。正如在后面讨论的那样，在即将发布的工具中，可以期盼获得静态检查支持方面的提高。
未来构建环境的考虑
AOP 工具的方面声明的简洁性，应当有助于判断该工具静态检查的优势。例如，Spring AOP 创建通知时要进行大量 XML 的搭配。某种工具要求的手工搭配越多，花在编写和调试这个搭配的时间就会越多，尤其在有许多方面的时候。从积极的方面来看，可以通过自动生成 XML 搭配来解决这个问题。稍后将讨论 JBoss AOP 的 Eclipse 插件，它能够做到这一点。
如果选择了 AspectJ 作为 AOP 工具，那么所有需要使用方面的 Java 项目都必须使用 AspectJ 的编译器。对于某些项目来说，这可能存在问题（例如在集中指定生产构建使用的编译器的情况下）。从积极方面来说，AspectJ 编译器打算替代 Java 编译器。另一个有关的考虑是：每种工具因为添加对方面的支持而带来的编译开销各不相同。下一节将详细讨论这一点。最后，还应当记住 AspectJ 的语言扩展方法要求项目中使用的所有与构建有关的工具都要扩展到 AspectJ。这意味着许多现成的解析 Java 代码的工具无法用于 AspectJ 代码（例如，基准和报告工具，依赖性和风格检查器，以及版本控制使用的 diff 工具）。
语言扩展在构建集成上的利弊
这一节将从构建集成的角度描绘 AspectJ 的语言扩展方法的一些主要利弊：
- 使用普通 Java 源代码的工具必须扩展才能用来处理方面代码。
- 需要使用不同的编译器。
+ 扩展的 Java 编译器提供了全部方面代码的完整静态检测。
+ 编写和调试切入点变得更加容易。
虽然语言扩展方法生来就有不足，但是它的一些优点将来也可以应用到注释和 XML 风格上。把这些优点提供给注释风格，正是 AspectJ 和 AspectWerkz 两个团队联合进行 @Aspect 开发工作的主要动机，而且这还表明，如果使用底层的 AOP 编译器，那么静态检查也能用于注释风格。目前，虽然还存在其他研究质量的编译器，但是 AspectJ 编译器是惟一达到商业质量的 AOP 编译器。注意，与采用不同编译器的必要性相关的许多关注点都是工具本身所固有的。在构建时、装入时或运行时修改这些字节码的时候，一些影响编译新字节码的问题也会出现。正如下一节将讨论的，这个编织（weaving） 过程是所有 AOP 工具的基本过程，因为是它支持横切关注点的模块化实现。
编织和性能
正如可以用不同的机制（例如，解释或编译成字节码或对象代码）编译和执行 OOP 程序那样，AOP 工具为构建和执行方面提供了不同的工具。方面编织器（aspect weaver） 提供了按照方面中切入点指定的方式自动调用通知的搭配方式。编织器可以接受源代码或二进制形式 AOP 代码作为输入。方面的编织对于性能和可伸缩性有影响，其中大部分取决于编织发生在应用程序生命周期的哪一部分。方面的编织可以在以下时间发生：
- 构建时 —— 如果 OOP 编译器已经扩展到 AOP，那么方面编织就是标准编译的一部分，否则就是编译后的步骤。
- 装入时 —— 与方面字节码的编译时编织相同，但是，是在类装入的时候进行编织。
- 运行时 —— 拦截和基于代理的机制提供了切入点匹配的手段，可以决定什么时候应当调用通知。
AspectJ 和 AspectWerkz 都支持构建时和装入时编织，但是 AspectJ 更侧重于前者，而 AspectWerkz 更侧重于后者。JBoss AOP 和 Spring AOP 则侧重于在运行时使用动态代理和拦截器调用方面。注意，也能将 Java VM 技术扩展到支持运行时编织，但目前这仍然处在研究阶段。使用运行时拦截框架的关键好处是：它很自然地扩展到了方面的热部署（hot deployment）。这意味着可以在运行时激活或禁用所应用的通知。
热部署是 JBoss AOP 的核心特性，它提供了一个应用服务器管理控制台，可以激活和禁止某些方面。在 Spring AOP 中也有热部署。加入 AspectWerkz 构建和装入时编织模型的类似扩展也支持热部署。在 AspectJ 中，用这种方式激活和禁止方面需要用通知中的 “ if” 测试或用 “if” 切入点进行。有时用术语“动态 AOP”来描述热部署，但是请注意，这个术语可能会造成误导，因为所有的 AOP 工具都支持动态连接点模型。而且 Spring AOP 完全基于代理机制。因此，这种工具很适合粗粒度的横切，但是纯粹基于代理的 AOP 不能用来通知精细的连接点（例如方法调用或字段设置）。另一方面，可以在没有构建时或装入时编织的情况下使用 Spring AOP 的代理，这对于某些应用服务器的部署会非常有用。
性能考虑
在 AOP 和性能的讨论中，需要重点关注的是关于 AOP 实现的性能的争论，它们与若干年前关于对象性能问题的争论类似。一般来说，使用方面的代码执行起来与纯粹面向对象的解决方案类似（这类方案中横切代码散落在整个系统中）。在大多数企业应用程序中，执行时间由远程调用和数据库调用决定，所以通常没有必要担心使用任何一种 AOP 工具时的开销。
也就是说，考虑一下AWBench 最新发布的 AOP 工具基准会很有价值（请参阅参考资料）。要理解这些基准，需要考虑 AOP 工具进行方面编织和编译的不同技术对性能的影响方式。
AspectJ 在编译时会带来开销，主要是内存和时间的使用，因为它是在编译时执行大部分通知。在大型项目中，这些开销有可能是很可观的，而且可能带来一些问题，特别是面向方面编程的横切特性通常意味着，在切入点发生变化时，大部分系统都需要重新编译。但它也意味着在运行的时候，几乎不需要为了匹配切入点做额外的工作。另外一个运行时的性能优势来自 AspectJ 和 AspectWerkz 中连接点参数的静态类型检查。这会带来性能飞跃，因为不需要以反射的形式访问连接点上下文了。对比之下，JBoss AOP 和 Spring AOP 基于拦截的技术在运行时有更多的工作要做。因此，在 AWBench 基准评定中可以看到一个趋势：AspectJ 的通知调用最快，然后是 AspectWerkz、JBoss AOP，最后是 Spring AOP。通过比较，AspectJ 的构建时开销最多，AspectWerkz 次之，JBoss AOP 再次，Spring AOP 没有构建时开销。
拦截的性能利弊
JBoss AOP 和 Spring AOP 使用的拦截和基于代理的 AOP 实现主要的性能利弊是什么？
+ 构建时间的内存和时间开销可以忽略不计。
- 运行时的通知调用开销，需要决定切入点匹配。
与任何性能度量标准一样，只能把这些准则当作参考，应当结合应用程序和使用情况来考虑这些准则。例如，与 Spring AOP 一起使用的典型粗粒度方面一般不会产生显著的开销。这里介绍的工具没有任何一个有让人无法接受的硬伤。与以前的一些 AspectJ 和 AspectWerkz 相比，这两种工具进行了更多的优化，其他工具正在紧紧追赶。AOP 编译器相对来说也是一种新发明，目前从研究社区到诸如 AspectJ 之类的实现的优化速度也在加快。当发生这些改进的时候，正如我们期望看到的那样，构建时间会在不断地改进。
IDE 集成
IDE 集成的目标是在熟悉的 IDE 中方便地编写和构建面向方面的程序。要达到这个目标，必须能够在 IDE 中调用 AOP 编译器或编织器。IDE 支持的另外一个主要职责是让系统的横切结构易于导航和理解。
在编辑切入点时，不得不运行系统才能查看结果，寻找受影响的连接点是非常耗时的。与此类似的问题是，开发人员在初次学习 AOP 时经常会问：“怎样才能知道方面在系统上的效果呢？如果其他人签入的方面会影响正在处理的方面又会怎样呢？”通过指出什么时候连接点受通知影响，AOP 工具回答了这些问题。这意味着在处理某个方法的时候，可以看到影响该方法的所有通知。反过来，在编写方面的时候，可以立即看到这个方面影响了哪个连接点。可以想像一下现代 Java IDE 是怎样提供方便的导航方式的，可以从一个方法导航到所有重写它的方法。这种面向对象工具支持使得系统的继承结构清晰可见。而 AOP IDE 支持使得横切结构的效果清晰可见，从而使处理某些方面就像处理对象一样容易。
插件比较
每种工具都提供了不同程度的 IDE 支持，在帮助项目选择合适工具的时候，这点可能很重要。研究实际使用 AspectJ 和 JBoss AOP IDE 插件可以让人对它支持的特性范围有个概念。下一节将进一步研究工具的 IDE 插件。
图 2 演示了用于 Eclipse 的 AspectJ 开发工具（AJDT）如何在编辑器中呈现出横切结构，以及如何呈现为了显示方面声明及其效果而扩展的视图。关于这些特性的详细描述以及更多截屏，请参阅参考资料中的 AJDT 文章。
图 2. 用于 Eclipse 的 AspectJ 开发工具（AJDT）插件 V1.2.0
下面将重点介绍一些 AJDT 插件的特性；列表编号与图中的标签对应：
- 包浏览器显示了一些方面和方面声明。切入点和声明出现时有它们自己的图标，这些图标指出了通知的种类（例如：before、after 等）。
- 编辑器支持显示了结构化的注释，允许从某个方面导航到被通知成员。内容辅助弹出对话框则显示了通知体中所有可以使用的连接点上下文。
- 文档大纲（Document Outline）表示活动编辑器的横切结构，代表影响对应连接点的通知和类型间声明。方面成形器（Aspect Visualiser）（在大纲下面，在这个压缩的截屏中勉强可以见到）显示了整个包中或项目中横切的整体效果，并突出了受通知影响的源代码行。
- 受通知影响的方法显示了可以用来导航到相应方面声明的引导注释。所有其他受影响的连接点都显示了相同的结构（例如，受类型间声明影响的类型，以及受通知影响的调用站点。）
像 AJDT 插件一样，JBoss AOP 插件也支持用视图在横切结构中导航。在图 3 中可以看到，Eclipse 的 JBoss AOP 插件提供了一些与 AJDT 插件相同的功能。它还有两个显著的额外特性：方面管理器视图，用于查看切入点绑定；还有一个 GUI，用于创建基于枚举的切入点。表 2 提供了这些插件特性的完整比较。
图 3. JBoss Eclipse 插件 V1.0.1
下面将重点介绍一些 JBoss AOP 插件的特性；列表编号与图 3 中的标签对应：
- 在包浏览器中，通知显得和普通 Java 成员一样。
- 方面管理器是 jboss-aop.xml 文件的图形化显示，可以减少由于缺乏静态检查而带来的问题（例如手工编辑 XML 的需要）。它还对程序的横切结构提供了方便的完整系统显示。
- Java 元素上的一个附加上下文菜单允许直接选取它们，将它们放入一个切入点中，无需编辑切入点表达式。
特性比较
表 2 总结了 4 种工具 IDE 特性当前的情况。它还提供了每种工具现有的库和文档情况的总结。然后是详细讨论。
表 2. IDE 支持、库和文档
下面的说明介绍了每种工具的 IDE 支持的关键特性：
- AspectJ —— AspectJ 主要的 IDE 支持是针对 Eclipse 的。Oracle JDeveloper、Borland JBuilder 和 Sun NetBeans 插件也提供了不同程度的 AspectJ 支持。但是，目前 JBuilder 和 NetBeans 版本的开发不是很活跃，因此大大落后于 AspectJ 语言的发行进度。随 AspectJ 提供的一个重要工具是
ajdoc，它可以为 AspectJ 程序生成 Javadoc 风格的文档。对于图 3 中看到的文档大纲中导航的横切结构，ajdoc 支持用 HTML 文档中的链接对这些结构进行导航。编辑器中的内容助手是一项新特性，对编写方面很有帮助，对那些对语言和各种原生切入点还不太熟悉的人也特别有用。
- AspectWerkz —— AspectWerkz 提供了初级的 Eclipse 插件。插件的成熟度落后于核心 AspectWerkz 实现的成熟度，至于真正的 IDE 支持，不要指望从 AspectWerkz 中可以得到（虽然这是联合 @AspectJ 时预期获得的一个好处）。
- JBoss AOP —— JBoss AOP 也侧重于 Eclipse 支持。JBoss 的 AOP 插件提供了方面管理器，它方便了 XML 配置文件的编辑。Advised Members 视图使得导航横切成为可能。JBoss 还有一个新的动态方面部署 UI，它为 JBoss AOP 提供了在运行时修改应用通知的方便。请注意，JBoss 的 AOP 插件是最近才发布的。它的成熟度还比不上 JBoss AOP 框架的其余部分。
- Spring AOP —— 在编译 XML 文件中的方面规范说明书时，Spring 的 Eclipse 插件会很有帮助，但它没有提供任何特定于 AOP 的功能。
所有的工具都依赖现有的 Java 调试器进行启动和调试。在所有的工具中，包括那些没有成熟 IDE 支持的工具（AspectWerkz 和 Spring AOP），方面程序的调试都工作得不错。这意味着在通知中和单步执行（single stepping）中设置断点与在普通 Java 类中是一样的。
有可能错过的特性
目前，所有的 IDE 插件中都还缺乏对重构的支持。所以，如果方法名改变，那么本来应当仍然匹配这个方法的切入点可能不再匹配。这是语言扩展不擅长的领域之一。在 AspectJ 不得不为重命名提供自己的重构支持的时候，在某种程度上，其他技术可以利用现有的重构支持。因为基于注释和 XML 风格的工具必须把完全限定 Java 切入点当作字符串，所以它们也可以借助重构工具，重新命名内嵌在 XML 文件和注释中的完全限定 Java 引用。
支持在 IDE 中使用 UML 视图的工具越来越多，尽管对这类视图的应用目前仍然存在争议。目前，还没有与 AspectJ 或其他 AOP 工具兼容的 UML 查看器。如果对 AspectJ 程序使用 UML 查看器，查看器可能会崩溃，因为它要求的是普通 Java 代码。相比之下，普通的 Java 技术会把方面作为普通的 Java 类显示。这样做的好处是有限的，因为它无法显示在通知与受影响的连接点之间，或者通知与通过类型间声明添加的附加成员之间的所有有意义的关系。
文档和库
除了 IDE 支持，工具的文档和库支持也是评估的重要因素。每种工具都提供了在线文档，但是 Spring 框架为其 AOP 功能提供的是有点分散的、以实现为中心的文档。无需 EJB 的 J2EE 和其他关于 Spring 框架的书籍会很快填补这个空白。AspectJ 是 AOP 工具的最好证明，目前有六本这方面的书正在印刷。注意，可使用文档的状态仅仅反映了每个项目已经进行的时间长短。
Spring AOP 提供了优秀的库支持。与 Spring 框架的集成意味着它利用了依赖注入的（dependency-injecting）方面，提供了复杂成熟的事务拦截器库，而且支持一些有趣的第三方方面（例如 Acegi 安全性框架）。Spring 的 AOP 库拥有在应用服务器之间移植的优点，而且精心挑选的框架组件方式使它很容易接纳模块中其他利用 AOP 支持的部分。JBoss AOP 提供了与 JBoss 框架和 JEMS 堆栈的其他部分的良好集成，而且拥有目前能够得到的最丰富的方面库。这些库包括对 JBoss Cache、J2EE 按需使用、JBoss remoting、异步方面和 JMX 方面的支持。目前，虽然已经用这些工具创建了一些第三方库，但 AspectJ 和 AspectWerkz 不包括任何库。未来的发行版承诺将提供库支持。
下一步是什么
评估 AOP 工具时要考虑的最后一个因素就是它们的下一步是什么。所有这些工具都在快速走向成熟，目前的实现工作正在解决这里讨论的许多问题。更有趣的是某些技术的优势正在渗透到其他技术中。例如，横切视图曾经是 AspectJ 所特有的，但现在 JBoss AOP 也提供了横切视图，而且很快其他工具也会提供。合并后的 @AspectJ 会把 AspectJ 工具支持的许多优点带到 AspectWerkz 的注释风格中。@AspectJ 还提供了语言扩展风格与注释风格之间的互操作性，这样，语言的语法也将成为开发人员的一个选择。
沿着这条路，对 AOP 重构的研究将会提供所有技术都能使用的结果。用于图形选择和切入点操作的 UI 将从一些常见的直观推断中受益，这些直观推断能够将选择和搜索结果转换成切入点。UML 视图也会开始显示 AOP 声明和联合。全面支持这些新特性是有可能的，这要感谢一些领先的 AOP 工具在语义上的汇集。
长远来看，性能应该是一个不是问题的问题。就像开发人员不该担心虚拟方法分派的开销一样，他们也不用担心通知的调用开销。目前在很大程度上这是事实，而且随着编织器的改进，以及与 JIT 和 VM 的集成越来越紧密，情况还会变得更好。
还有另外两个趋势正在出现，但是还不确定。首先，AOP 的连接点模型和切入点机制的适用性超越了编程语言，对于能够从描述运行时事件的简洁语言中受益的其他工具来说，AOP 的连接点模型和切入点机制也很适用。随着越来越多的人采用 AOP 工具，切入点的应用在调试器、profiler 这类工具中的应用可能越来越普遍。例如，可以在特定的控制流程中设置断点。另一个正在出现的趋势与模型驱动的开发（model-driven development MDD）有关。由于横切的问题在系统中是如此基本的一个问题，所以 MDD 工具会从模型化的横切结构以及生成的方面中获益。
以下是期望从这些工具即将发布版本中得到的一些具体特性的列表：
- AspectJ 和 AspectWerkz —— AspectJ 5 会提供对切入点泛型的支持特性。@AspectJ 语法会支持 AspectWerkz 注释风格。
- JBoss AOP —— 参数的静态类型化、性能提高、库和更多的 IDE 支持特性。
- Spring AOP —— 性能提高、与 AspectJ 切入点的互操作性，以及把某些 Spring AOP 服务打包成 AspectJ 方面。
底线
如果存在这里给出的优势和不足，如何判断为特定项目选择哪个工具？在采用某项技术时可能遇到的主要问题是什么？这里是每种工具的强项与弱点的一个概括，可以帮助您制定最终决策。下面将开始介绍手工编写横切问题与使用 AOP 工具进行处理的优劣对比。
所有工具 VS 手工编码的横切
- 目前还不支持高级 IDE 特性（例如重构）。
+ 一些方面天生就处于复杂系统中，如果没有 AOP 工具，实现会变得非常脆弱，难以发展。
+ 横切变得很明确，易于推理和修改。
AspectJ
- 语言扩展要求使用已扩展的编译器和相关工具。
- 缺少库。
+ 简洁的方面声明和切入点的静态检查。
+ 成熟的 IDE 集成。
+ 丰富的文档。
AspectWerkz
- 不太简洁的方面和切入点声明。
- 缺少切入点的静态检查。
- 缺少库。
+ 与 AspectJ 类似的机制，没有语言扩展。
+ 支持方面的热部署。
JBoss AOP
- 缺少切入点的静态检查。
- 缺少到其他应用服务器的移植性。
+ 有丰富的企业方面库集合可用，与丰富的 JBoss 和 JEMS 库集成在一起。
+ IDE 支持降低了采用难度，减少了手工编写 XML 代码的需要。
+ 支持方面的动态部署。
Spring AOP
- 只能通知那些通过框架的代理机制实例化的对象。
- 不适合细致的方面。
- 缺少处理方面的 IDE 支持。
+ 简单的连接点模型很适于粗粒度的方面，更容易学习。
+ Spring 框架集成，易于现有 Spring 用户采用。
+ 跨应用服务器的方面库可移植性。
结束语
AOP 工具目前的成就让人对它的发展前景感到兴奋，之所以特别有兴趣在这里研究这 4 种工具，是因为它们目前的成熟度，以及对它们未来开发的展望。这里选择进行比较的 4 种工具都足够成熟，均适用于商业开发，并且会在将来的某个时候获得成功。
仔细分析这篇由两部分构成 AOP 工具比较系列文章中讨论的该工具的利弊，这些有助于判断哪种工具最适合您的项目。文中指出了工具处理方面声明、编织以及构建集成的主要区别，概述了关键的性能问题；还强调了 IDE 集成的好处。本文概述了 Java 语言扩展的优势与不足，这个主题对 Java 开发人员有深远的意义，文章还指出了 AOP 工具的一些未来发展方向。
在阅读本文时，读者可能会很惊讶地发现这些工具的相同点要多于它们的不同点。这意味着不管选择哪项技术，学习曲线可以从一个 AOP 工具转移到另一个。每种工具的新发展会继续相互渗透。AOP 工具目前正在迅速发展，可以满足不断增长的用户社区的需求；而且它还在不断发布新版本。不管您最后采用什么样的 AOP 工具，都鼓励您加入它的用户讨论列表。您的反馈会帮助这项重要的技术指明未来的发展方向。
记着下个月继续关注 AOP@Work 系列的下一期文章：Ramnivas Laddad 的 “元数据和 AOP：天生绝配”。
参考资料
关于作者
Mik Kersten 是一流的面向方面的编程专家，也是 AspectJ 和 AJDT eclipse.org 项目的参与者。作为 Xerox PARC 的研究科学家，他为 AspectJ 构建了 IDE 支持。他正在不列颠哥伦比亚大学攻读博士学位，他的主要工作是使 IDE 更加面向方面。他也向构建开发工具的公司提供咨询，帮助公司利用、支持面向方面的编程技术。 |
|