?
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
當你確定切面是實現(xiàn)一個給定需求的最佳方法時,你如何選擇是使用Spring AOP還是AspectJ,以及選擇 Aspect語言(代碼)風格、@AspectJ聲明風格或XML風格?這個決定會受到多個因素的影響,包括應用的需求、 開發(fā)工具和小組對AOP的精通程度。
做能起作用的最簡單的事。Spring AOP比完全使用AspectJ更加簡單, 因為它不需要引入AspectJ的編譯器/織入器到你開發(fā)和構(gòu)建過程中。 如果你僅僅需要在Spring bean上通知執(zhí)行操作,那么Spring AOP是合適的選擇。 如果你需要通知domain對象或其它沒有在Spring容器中管理的任意對象,那么你需要使用AspectJ。 如果你想通知除了簡單的方法執(zhí)行之外的連接點(如:調(diào)用連接點、字段get或set的連接點等等), 也需要使用AspectJ。
當使用AspectJ時,你可以選擇使用AspectJ語言(也稱為“代碼風格”)或@AspectJ注解風格。 很顯然,如果你用的不是Java 5+那么結(jié)論是你只能使用代碼風格。 如果切面在你的設(shè)計中扮演一個很大的角色,并且你能在Eclipse中使用AspectJ Development Tools (AJDT), 那么首選AspectJ語言 :- 因為該語言專門被設(shè)計用來編寫切面,所以會更清晰、更簡單。如果你沒有使用 Eclipse,或者在你的應用中只有很少的切面并沒有作為一個主要的角色,你或許應該考慮使用@AspectJ風格 并在你的IDE中附加一個普通的Java編輯器,并且在你的構(gòu)建腳本中增加切面織入(鏈接)的段落。
如果你選擇使用Spring AOP,那么你可以選擇@AspectJ或者XML風格。顯然如果你不是運行 在Java 5上,XML風格是最佳選擇。對于使用Java 5的項目,需要考慮多方面的折衷。
XML風格對現(xiàn)有的Spring用戶來說更加習慣。它可以使用在任何Java級別中 (參考連接點表達式內(nèi)部的命名連接點,雖然它也需要Java 5+) 并且通過純粹的POJO來支持。當使用AOP作為工具來配置企業(yè)服務(wù)時XML會是一個很好的選擇。 (一個好的例子是當你認為連接點表達式是你的配置中的一部分時,你可能想單獨更改它) 對于XML風格,從你的配置中可以清晰的表明在系統(tǒng)中存在那些切面。
XML風格有兩個缺點。第一是它不能完全將需求實現(xiàn)的地方封裝到一個位置。 DRY原則中說系統(tǒng)中的每一項知識都必須具有單一、無歧義、權(quán)威的表示。 當使用XML風格時,如何實現(xiàn)一個需求的知識被分割到支撐類的聲明中以及XML配置文件中。 當使用@AspectJ風格時就只有一個單獨的模塊 -切面- 信息被封裝了起來。 第二是XML風格同@AspectJ風格所能表達的內(nèi)容相比有更多的限制:僅僅支持"singleton"切面實例模型, 并且不能在XML中組合命名連接點的聲明。例如,在@AspectJ風格中我們可以編寫如下的內(nèi)容:
@Pointcut(execution(* get*())) public void propertyAccess() {} @Pointcut(execution(org.xyz.Account+ *(..)) public void operationReturningAnAccount() {} @Pointcut(propertyAccess() && operationReturningAnAccount()) public void accountPropertyAccess() {}
在XML風格中能聲明開頭的兩個連接點:
<aop:pointcut id="propertyAccess" expression="execution(* get*())"/> <aop:pointcut id="operationReturningAnAccount" expression="execution(org.xyz.Account+ *(..))"/>
但是不能通過組合這些來定義accountPropertyAccess
連接點
@AspectJ風格支持其它的實例模型以及更豐富的連接點組合。它具有將切面保持為一個模塊單元的優(yōu)點。 還有一個優(yōu)點就是@AspectJ切面能被Spring AOP和AspectJ兩者都理解 - 所以如果稍后你認為你需要AspectJ的能力去實現(xiàn)附加的需求,那么你非常容易遷移到基于AspectJ的途徑。 總而言之,我們更喜歡@AspectJ風格只要你有切面去做超出簡單的“配置”企業(yè)服務(wù)之外的事情。