AOP@Work: AOP和元数据:完美的匹配,第1部分 - 编程入门网
addad
利用基于元数据的子方面,当类中的连接点改变其特性时,只有这个连接点的 注释需要改变。清单 6 显示了扩展 版本 2 中的 TxMgmt方面的子方面,并通过 捕获所有携带类型为 Transactional 的注释的所有方法来定义 transactedOps() 切入点。 清单 6. 元数据驱动的事务管理子方面
这个类必须通过向每一个需要在事务管理中执行的方法上附加类型为 Transactional 的注释与子方面进行协作。清单 7 显示了类 Customer 的实现, 其方法中包含以下注释: 清单 7. 带有注释的 Customer 类
清单 8 显示了 Account 类的类似实现: 清单 8. 带注释的 Account 类
AOP@Work: AOP和元数据:完美的匹配,第1部分(14)时间:2011-09-04 IBM Ramnivas Laddad这时,我已经建立方法与协作方面之间的一对一依赖关系。我去除了方面与类 之间的直接依赖关系。结果,在想要改变基本方面时,现在可以不用对系统的任 何地方做任何改变。 基本方面的使用是可选的(也就是说您可以减少分层结构)。不过,将基本方 面与元数据驱动的子方面分离具有若干好处。首先,派生的方面可以选择注释类 型。在一个系统中,可以使用 Transactional 作为注释类型来捕获连接点,而在 另外的系统中,注释类型可以是 Tx。其次,它为派生的方面提供了 Participant 模式与元数据驱动的方法的选择。第三,这种方法使得从像 @Purchase 或者 @OrderProcessing 这样的业务注释中派生出事务切入点成为可能。最后,它使元 数据驱动的方法与基于 Participant 的方法的结合成为可能。 通过借助注释的合作,参与责任被转移给了每个方法(而不是参与者子方面) 。MetadataDrivenTxMgmt 与类之间的依赖关系局限于注释类型及它们相关的语义 。 在大多数情况下,这个版本已经足够好了。不过,还有一个特殊的场景,我可 以再进一步努力,以得到最佳的结果。 版本 5: Aspect 作为元数据供应者 在某些情况下,类中的大多数方法需要携带注释(如 版本 4 中所示)。而且 ,许多横切特性需要每个方法有一个或者多个注释。这种条件会使每个方法声明 许多注释,这种情况通常称为注释地狱。结合 Participant 模式与注 释者-供应者方面可以减少注释混乱。在有明确的方法表示特定的连接点时,这是 一种有用的选择。在这种情况下,有一种注释者-供应者设计避免了错过连接点的 注释的风险。 图 5. Aspect 作为元数据供应者 AOP@Work: AOP和元数据:完美的匹配,第1部分(15)时间:2011-09-04 IBM Ramnivas Laddad注释者方面只是使用一个或者多个 declare annotation:例如,declare annotation : <Method pattern> : <Annotation definition>;。 在这个例子中,我使用了 Participant 模式类型的协作,每个类有一个注释者方 面。不过,这样做不是这种设计的必备要求。比如说,您可以为每个包实现一个 注释者。核心思想是找出一个合适的子系统,它具有明确的签名模式或者动态上 下文信息(控制流程等),可以捕获所需要的连接点,并避免这种情况下的注释 混乱。清单 9 显示了带有注释者方面的 Custo |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |