Ramnivas Laddad谈AOP选型

作者 Srini Penchikala 译者 王丽娟 发布于 2009年1月11日

领域

架构 & 设计

主题

AOP ,

架构

标签

AOP ,

AJDT ,

AspectJ ,

面向方面编程（AOP）

Spring AOP/AspectJ搭配能提供多种选择，比如AOP系统的选择（基于字节码的AOP或基于代理的AOP）、语法的选择（传统的AspectJ、@AspectJ或XML语法），还有织入方式的选择（构建时织入器或加载时织入器）；在企业应用中使用AOP时，清楚地理解这些选择对实施的效果来说是非常重要的。

Ramnivas Laddad说，只有一种AOP是不能适用于所有应用的，选择正确的组合有助于开发人员成功使用AOP。他在近期的SpringOne Americas大会上做了演讲，谈论了各种AOP设计、Spring AOP框架提供的实现选择，还有Web应用中使用AOP的最佳实践。

Ramnivas讨论了AspectJ织入和基于代理的Spring AOP方法的优势与不足。在Spring AOP和AspectJ之间进行选择取决于设计和环境因素。在下述情况下使用Spring AOP：

• 单纯的方法拦截就足够了。
• 全套的AOP功能显得太多。
• 不想使用特殊的编译器，比如AspectJ编译器（ajc）。
• 不需要横切领域对象。
• 预先提供的方面已经能满足需求。

其它情况使用AspectJ AOP。他列举了一些AspectJ（细粒度跟踪和监控，领域对象，细粒度安全）和代理AOP（事务管理，JMX监控，远程访问和安全）的例子应用。在演讲过程中，Ramnivas用代码示例展示了传统AspectJ和@AspectJ语法这两种选择之间的差异。

方面织入选型包含编译时织入和加载时织入（LTW）。使用LTW时，你可以使用允许方面织入的Spring驱动LTW，该LTW不用修改任何容器启动脚本（没有-javaagent参数），也无需利用Spring使用配置选项的JPA代理。这两种织入选择之间的比较如下：

构建时织入（编译/二进制）：

• 织入在构建时花费时间，但在加载时是全速的。
• 需要修改构建系统。
• 无须任何部署修改。
• 最好的IDE支持——Eclipse AspectJ Development Tools（AJDT）。

加载时织入：

• 加载时速度和内存占用会受到影响。
• 不用改变构建系统，但为了织入方面，需要修改部署。
• 没有IDE工具的支持。

AOP设计选择包括利用连接点签名（join point signatures）的切入点实现和使用通配符选择大范围的连接点。元数据（注解）也可用来捕获连接点，该方法有如下优势和不足：

• 优势：
  用注解捕获应用中特定的横切关注点是一种很简单的方式。注解有助于把方面和类之间的协作只限定于注解。
• 不足：
  必须需要类的协作。另外，过度利用注解可能会掩盖AOP的遗忘性（obliviousness）。

AOP实现使用元数据的最佳实践有：

• 注解是表达程序元素固有特性的最佳选择。
• 注解应该描述清楚连接点上什么是符合要求的，而不是在这些点上应该发生什么。
• 避免特定实现的注解。
• 注解应该描述被注解元素的状态。举例来说，为了捕获一个只读场景，用@ReadOnly作为注解名，而不要用@TakeReadLock。要标记一个需要具有事务性的方法，使用@Transactional，而不要用@JTATransactional。
• 不要用注解创建宏。
• 使用已有的注解，诸如JPA（@Entity、@Table）、JAX-WS（@WebService、@WebMethod）、Spring（@Component、@Service、@Autowired、@ManagedResource）。

查看英文原文：Ramnivas Laddad on Making AOP Choices With AspectJ and Spring AOP

译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。

1. 返回顶部

   使用框架兼容方案就行了, 没想过特意地去选择

   发表人 张 丹

   就像上文所说的"单纯的方法拦截就足够了"
   一般就是控制到这个程度的, 用spring aop, 可以在XML里写, 也可以用@.
   AOP只是程序的一个部分, 业务逻辑还是要用传统的方式实现.
   
   如果说整个应用是完全基于AOP开发的, 估计选型就是重点问题了.

   回复

• 更早的 >