清单 2. Account 类的业务客户

public class AccountServices { 　　@Transactional(Required) 　　public void transfer(Account to, Account from, float amount) { 　　　　to.credit(amount); 　　　　from.debit(amount); 　　} }

AOP@Work: AOP和元数据：完美的匹配，第2部分-用元数据实现多维接口(5)

除了它所携带的注释（在这里的讨论中可以忽略）之外，这个方法实现没有什 么特别的。特别是，业务客户（transfer() 方法）不知道或者不关心 credit() 或者 debit() 方法的事务维或认证维。

与业务客户一样，事务管理方面只关心它自己的维。（注意，清单 3 对本文 第 1 部分的清单 2 中所示的方面进行了重构。）

清单 3. 事务管理方面

public aspect TxMgmt { 　　public pointcut transactedOps (Transactional tx) 　　: execution(@Transactional * *.*(..)) 　　 　&& @this(tx); 　　Object around(Transactional tx) : transactedOps(tx) { 　　　　if(tx.value() == Required) { 　　　　 　　... 　　　　} 　　} }

事务管理方面只使用投射到事务管理方面中的接口。换句话说，不管所考虑的 方法叫 credit() 还是 foo()，这个方面所关心的都是一样的。

利用元数据描述方面化的接口是一种强大的概念。将元数据考虑为类中的一个 方面化接口，通过这种方法来横切系统中的一些关注点，这样，可以将面向对象 世界中的一些最佳实践应用到 AOP 中。例如，不会将一个方法命名为 creditUsingJDBC()，因为希望只描述方法在业务关注空间的功能，而“JDBC”不 是这个空间的一部分。对于方面化的接口也是一样：您可能不想使用名为 ReadLock 的注释类型，这类注释的用途是描述类型的使用。 ReadOperation 是 更好的类型，它向外界描述了这个接口。

在 AOP 编程中使用元数据将类与方面之间的耦合限制为附加在程序元素上的 元数据。将这个概念延伸到支持元数据的多维接口时，可以看到每一个方面都只 耦合到相关的接口。因此，方面与类之间的耦合与面向对象的编程中类之间的耦 合没有什么不同。

正确使用元数据的准则

虽然元数据在与 AOP 共同使用时特别有用，但是会有过度使用的危险。过度 使用注释会使包含在程序元素的签名和动态上下文中的原有信息无法得到充分利 用。在代码中加入元数据还会增加代码的复杂性。首先，程序元素必须包含元数 据注释。其次，不正确地在 AOP 中使用元数据会导致 macros on steroids，初 看之下，它非常有用，可以节省大量重复的代码，但它会使程序变得越来越难以 理解。因此，除了了解组合使用 AOP 与元数据所涉及的机制之外，掌握组合使用 这两种技术所必需的概念和最佳实践也很重要。在这一节中，我将提供一组正确 结合元数据与 AOP 的准则。

1. 如果不需要就不要使用它

如果所考虑的程序元素在其本来的签名和动态上下文中包含捕获所需的连接点 的足够信息，那么就没有理由附加注释。加入了注释并写下切入点来使用这些注 释之后，任何没有 注释的元素都不能参与关注点的横切。因此，总是要首先考虑 使用元数据的这些替代方法：

要全局地对待全局关注点：程序元素不应当对关注点（比如在横切实现中进行 跟踪和分析）的参与起什么作用。例如，在需要分析的元素上附加 @Profiled 注 释没有什么意义。所分析的元素应当是在全局范围内选取的，并且它们的选取取 决于当前分析目标。在这种情况下使用注释意味着系统分析目标发生改变时要修 改程序元素。在这种情况下，利用基于包和继承层

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!