AOP@Work: AOP工具比较，第1部分-语言机制 - 编程入门网
| 束 AOP 工具比较的第一部分的讨论。 表 4 是 4 个工具的 AOP 语言的概括。下面讨论了最明显的区别。
表 4. 领先的 AOP 工具的语义概括
AOP@Work: AOP工具比较，第1部分-语言机制(9)时间:2011-09-04 IBM Mik Kersten切入点匹配和复合：AspectJ、AspectWerkz 和 JBoss AOP 提供了类似的类型 模式支持。它们三个都允许签名方面的匹配，对于 Java 5 应用程序来说，这些 匹配包括注释和泛型。AspectJ 和 AspectWerkz 提供了一种简洁的引用多个类型 的技术（例如 Account+ 表示帐户的所有子类型）。所有的工具都支持通配符匹 配。Spring AOP 还提供了对正则表达式的支持。虽然这看起来可能是一个强大的 优势，但还是要指出其他技术已经选择了放弃正则表达式，好让切入点读起来不 是太难，同时不会存在潜在的损害。切入点复合操作符基本上都是相同的。 Spring AOP 不提供“非”操作，这个操作通常与没有在 Spring AOP 连接点模型 的容器（containment）连接点结合使用。 通知形式：AspectJ 支持比其他技术更多的通知形式，而 JBoss AOP 只支持 一种通知形式。每种通知形式都可以表达成 around 通知，所以 JBoss 的技术是 无限的，而且它确实提供了额外的简单性。不好的一面是它损失了简洁性，这一 点可以从需要进行额外的调用才能继续执行原来的方法调用（如 图 4 所示）看 得出来，而如果用 before 进行通知，这一点就是不必要的。还请注意，强迫通 知去遵守普通的 Java 规则（就像注释和 XML 风格做的那样），在一些情况下容 易出问题，因为这些规则是为方法设计的。AspectJ 拥有把被通知方法的异常“ 软化”的能力，这很有用，但是不符合方法异常检测的标准语义。 连接点上下文：在 AspectJ 和 AspectWerkz 中，通过指定和绑定切入点参数 访问动态连接点的状态，类似于在 Java 语言中声明方法参数的技术（请参阅图 2 和 图 3）。这为连接点上下文提供了静态类型化的好处。JBoss AOP 和 Spring AOP 反射性地访问连接点的状态，这消除了在切入点表达式中参数绑定的 复杂性，代价是参数静态类型化。Java 程序员习惯了方法参数静态类型化带来的 好处，同时还可以从切入点参数的静态类型化得到同样的好处。所以，在 JBoss AOP 最近的发行版本中，有提供静态类型化的“args” 的计划。 实例化：在所有的工具中，方面的实例化是由 per 子句控制的。正如所料， Spring AOP 的实例化模型更简单。对于额外的实例化机制的支持，则意味着可以 把方面编写成只能应用于特定的动态上下文环境中，不用编写代码保存这个上下 文并测试其他方面是否该应用这个方面。主要的区别因素是 AspectJ 支持在每个 控制流程进行方面初始化，AspectWerkz 支持每个线程的初始化，而 JBoss 则支 持每个连接点的初始化。哪种最有用则取决于具体的需求。 扩展性：方面的扩展性支持库方面的部署，这样可以在日后为特定程序而将这 些库方面具体化。例如，一个方面库可以提供应用程序监视需要的全部逻辑和基 础设施。但是，要采用某个特定项目的库，那么库使用的切入点必须扩展成应用 程序特定的连接点。AspectJ 用抽象方面支持扩展性，抽象方面包含抽象的切入 点和具体的通知。扩展抽象方面的子方面必须具体化切入点。AspectWerkz 和 JBoss AOP 使用了完全不同的技术，没有使用抽象切入点机制。扩展是通过生成 方面的子类、并在 XML 中或通过注释定义新的通知绑定而实现的。切入点到通知 的显式绑定为 AspectWerkz 和 JBoss AOP 提供了显著优势，从而可以很容易地 把方面扩展到新系统，无需要生成子类。方面库的使用数据正在日益增多，这些 将决定与其他技术使用的 Java 风格的继承和切入点绑定相比，AspectJ 特殊的 AO |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
