Spring 2.0和Spring AOP
在Spring 2.0中最激動(dòng)人心的增強(qiáng)之一是關(guān)于Spring AOP，它變得更加便于使用而且更加強(qiáng)大，主要是通過復(fù)雜而成熟的AspectJ語言的支持功能來實(shí)現(xiàn)，而同時(shí)保留純的基于代理的Java運(yùn)行時(shí)。
我們一直堅(jiān)信AOP（面向切面編程）很重要。為什么？因?yàn)樗峁┙o我們一種新的思考程序結(jié)構(gòu)的方法，能夠解決很多純OOP無法解決的問題——讓我們能夠在一個(gè)模塊中實(shí)現(xiàn)某些需求，而不是以發(fā)散的方式實(shí)現(xiàn)。
為了理解這些好處，讓我們考慮一些我們可以在需求中表達(dá)但無法直接用純OO代碼實(shí)現(xiàn)的情況。企業(yè)開發(fā)者使用一個(gè)通常的詞匯表來讓他們進(jìn)行清楚的溝通。比如，像服務(wù)層，DAO層，Web層或者Web控制器這樣的術(shù)語，這不需要什么解釋。
許多需求是用這個(gè)詞匯表中的術(shù)語來表達(dá)的。比如：
◆服務(wù)層應(yīng)該是可以處理事務(wù)的。
◆當(dāng)DAO操作失敗時(shí)，SQLException或者其他特殊持久化技術(shù)的異常應(yīng)該被翻譯，以確保DAO接口不會(huì)有漏掉的抽象。
◆服務(wù)層對(duì)象不應(yīng)該調(diào)用Web層，因?yàn)楦鲗討?yīng)該只依賴直接處在其下方的層。
◆由于并發(fā)相關(guān)操作的失敗而導(dǎo)致失敗的等冪業(yè)務(wù)服務(wù)可以重試。
雖然這些需求都是現(xiàn)實(shí)存在的，并來自于經(jīng)驗(yàn)，但它們并不能用純OOP來優(yōu)雅地解決。為什么？主要有兩個(gè)原因：
◆這些來自于我們?cè)~匯表的術(shù)語有意義，但它們并不是抽象。我們不能使用術(shù)語編程；我們需要抽象。
◆所有這些都是所謂橫切關(guān)注點(diǎn)的例子。一個(gè)橫切關(guān)注點(diǎn)，在用傳統(tǒng)OO方法實(shí)現(xiàn)時(shí)，會(huì)分解成很多類和方法。比如，想象一下在跨DAO層遭遇特殊異常時(shí)要使用重試邏輯。這個(gè)關(guān)注點(diǎn)橫切許多DAO方法，而且在傳統(tǒng)的方式中會(huì)需要實(shí)現(xiàn)許多單獨(dú)的修改。
AOP就是通過對(duì)橫切關(guān)注點(diǎn)進(jìn)行模塊化，并讓我們從普通的還可以編程的抽象的詞匯表來表達(dá)術(shù)語，來解決這樣問題的技術(shù)，這些抽象叫做切入點(diǎn)，我很快會(huì)再解釋一些關(guān)于它們的細(xì)節(jié)。這種方法帶來一些主要好處，比如：
◆因?yàn)闇p少了剪切粘貼風(fēng)格的復(fù)制而減少代碼行數(shù)。這在像異常轉(zhuǎn)換和性能監(jiān)測這樣的try/catch/finally習(xí)慣用法中尤其有效。
◆在單個(gè)代碼模塊中捕捉這樣需求的能力，提升可追蹤能力。
◆在單個(gè)地方修補(bǔ)bug的能力，而不需要重新訪問應(yīng)用程序中許多位置。
◆確保橫切關(guān)注點(diǎn)不混淆主要的業(yè)務(wù)邏輯——隨著開發(fā)的進(jìn)展，這很有可能成為危險(xiǎn)之處。
◆開發(fā)者和團(tuán)隊(duì)之間更好的職責(zé)分離。比如，重試功能可以有單個(gè)開發(fā)者或者團(tuán)隊(duì)來編碼，而不需要由許多開發(fā)者跨多個(gè)子系統(tǒng)進(jìn)行編碼。
因此AOP很重要，我們想提供***的解決方案。
Spring AOP無疑是最廣泛使用的AOP技術(shù)，歸功于以下優(yōu)點(diǎn)：
◆采用成本幾近為零。
◆提供正確的切入點(diǎn)，這才稱得上是AOP而不僅僅是攔截。
◆提供一個(gè)支持許多使用方式的靈活的框架，可編程也可通過XML。
然而，在Spring 2.0之前，Spring中的AOP有一些缺點(diǎn)：
◆不寫Java代碼，只能表達(dá)簡單的切入點(diǎn)。并沒有一種切入點(diǎn)表達(dá)語言來以字符串形式，簡潔表達(dá)復(fù)雜的切入點(diǎn)，雖然RegexpMethodPointcutAdvisor允許定義簡單正規(guī)的基于表達(dá)的切入點(diǎn)。
◆當(dāng)配置復(fù)雜AOP使用場景時(shí)，XML配置會(huì)變得很復(fù)雜。泛型元素被用來配置AOP類；雖然這對(duì)一致性來說很棒，對(duì)切面和類提供DI和其他服務(wù)，但它沒有一個(gè)專門的配置方法來得簡潔。
◆Spring AOP不適合通知細(xì)粒度的對(duì)象——對(duì)象需要由Spring管理或者通過編程被代理。
◆基于代理的方法的性能負(fù)載在少數(shù)案例中成為問題。
◆因?yàn)镾pring AOP分離了代理和目標(biāo)（被修飾或者被通知的對(duì)象），如果某個(gè)目標(biāo)方法調(diào)用了目標(biāo)上的方法，就不會(huì)使用到代理，意味著AOP通知并不適用。AOP使用基于代理的方法的正反面影響超出了本文的范圍：有一些積極的因素（比如能夠?qū)ν粋€(gè)類的不同實(shí)例應(yīng)用不同的通知），但主要還是消極的。
為了在Spring 2.0中增強(qiáng)這個(gè)重要領(lǐng)域，我們希望在它的優(yōu)勢上構(gòu)建，同時(shí)解決缺點(diǎn)。
***的兩個(gè)缺點(diǎn)也是最顯著的。它們都跟切入點(diǎn)相關(guān)。后面的三個(gè)缺點(diǎn)在Spring用戶的正常使用中很少發(fā)生，如果它們證明是的確有問題的，我們建議使用AspectJ。（就像你會(huì)看到的，這是Spring AOP直接的進(jìn)步。）
XML配置擴(kuò)展解決了關(guān)鍵的挑戰(zhàn)之一。因?yàn)槲覀兿胍３諷pring模塊的設(shè)計(jì)，我們過去不能在Spring DTD中提供特定于AOP的標(biāo)簽——因此在這種情況下需要依賴可以詳細(xì)一點(diǎn)的通用配置。隨著Spring 2.0的出現(xiàn)，這樣的問題沒有了，因?yàn)閄ML schema并不像DTD，它允許擴(kuò)展。我們可以提供一個(gè)AOP命名空間，看起來能讓Ioc容器識(shí)別AOP結(jié)構(gòu)，但不會(huì)影響模塊化。
AOP術(shù)語101：理解切入點(diǎn)和通知
讓我們簡要地修正一下某些AOP術(shù)語。如果你使用過AOP這些概念，可能對(duì)你來說很熟悉——這些概念是相同的，僅僅有一點(diǎn)不同，即更加優(yōu)雅和強(qiáng)大的表達(dá)方式。
切入點(diǎn)是匹配規(guī)則。它在程序執(zhí)行中確定應(yīng)該應(yīng)用某個(gè)切面的點(diǎn)的集合。這些點(diǎn)叫做連接點(diǎn)。在應(yīng)用程序運(yùn)行時(shí)，連接點(diǎn)隨時(shí)會(huì)有，比如對(duì)象的實(shí)例化和方法的調(diào)用。在Spring AOP（所有版本）的案例中，唯一支持的連接點(diǎn)是公有方法的執(zhí)行。
通知是可以被切面應(yīng)用到連接點(diǎn)的行為。通知能在連接點(diǎn)之前或之后應(yīng)用。通知的所有類型包括：
◆Before advice：在連接點(diǎn)之前調(diào)用的通知。比如，記錄方法調(diào)用即將發(fā)生的日志。
◆After returning adive：如果在連接點(diǎn)的方法正常返回時(shí)調(diào)用的通知。
◆AfterThrowing advice（在Spring1.x中叫做Throws通知）：如果連接點(diǎn)的方法拋出一個(gè)特殊的異常時(shí)調(diào)用的通知。
◆After advice：在連接點(diǎn)之后調(diào)用的通知，無論結(jié)果是什么。特別像Java中的finally。
◆Around advice：能夠完全控制是否執(zhí)行連接點(diǎn)的通知。比如，用來在事務(wù)中封裝某個(gè)方法調(diào)用，或者記錄方法的執(zhí)行時(shí)間。
切面是結(jié)合切入點(diǎn)和通知成一個(gè)模塊方案，解決特殊的橫切問題。
如果這有點(diǎn)抽象，請(qǐng)不要擔(dān)心：代碼示例會(huì)很快解釋清楚的。
對(duì)在Spring 2.0和AspectJ的環(huán)境中關(guān)于AOP基礎(chǔ)的更深討論，請(qǐng)參考Adrian在InfoQ上很棒的文章，"Simplifying Enterprise Applications with Spring 2.0 and AspectJ."
為什么會(huì)是AspectJ切入點(diǎn)表達(dá)式？
迄今為止，我們討論過的概念都是基本的AOP概念，對(duì)于Spring AOP或者AspectJ而且這并不特別，在Spring1.x中已經(jīng)是存在的。那么為什么我們選擇在Spring 2.0中采用AspectJ呢？
如果我們需要一種切入點(diǎn)表達(dá)語言，那么選擇就會(huì)很簡單。AspectJ有個(gè)思路很好，嚴(yán)格定義和充足文檔的切入點(diǎn)語言。它最近實(shí)現(xiàn)了一個(gè)當(dāng)在Java 5上運(yùn)行時(shí)，能對(duì)采用Java 5語法的編碼全面檢查。它不僅有很棒的參考材料，而且很多書籍和文章都對(duì)它進(jìn)行了介紹。
我們不相信重新發(fā)明的輪子，而且定義我們自己的切入點(diǎn)表達(dá)語言是不合理的。進(jìn)一步而言，自從AspectWerkz在2005年早期和冰島AspectJ項(xiàng)目之后，很明顯AspectJ是除了Spring 2.0之外唯一一個(gè)主流的AOP技術(shù)。因此關(guān)鍵的合并既是一種考慮也是一種技術(shù)優(yōu)勢。
【編輯推薦】
