 |
|
| 內(nèi)容： |
|
|
|
|
| 相關(guān)內(nèi)容： |
|
|
|
|
| 訂閱: |
|
|
|
| 語言機(jī)制
Mik Kersten
AOP 工具構(gòu)建師、咨詢顧問, University of British Columbia
2005 年 2 月
AOP 技術(shù)的時(shí)代已經(jīng)來臨，但是怎樣才能為項(xiàng)目選擇正確的工具呢？在新推出的 AOP@Work 系列的第一篇文章中，面向方面（aspect-oriented）的編程專家 Mik Kersten 將比較 4 個(gè)領(lǐng)先的 AOP 工具（AspectJ、AspectWerkz、JBoss AOP 和 Spring AOP），幫助大家判斷應(yīng)該選擇哪一個(gè)工具。本文由兩個(gè)部分組成，在文中，作者將重點(diǎn)介紹這些工具的語言機(jī)制和不同技術(shù)的優(yōu)劣。他分別用 4 種工具編寫同一個(gè)示例，讓讀者感覺到它們之間的高級(jí)區(qū)別。他還將討論每種工具的語法技術(shù)對 AOP 語義產(chǎn)生的效果。在文章結(jié)束時(shí)，作者將對工具的核心語言機(jī)制（例如切入點(diǎn)匹配和組合、通知的格式、連接點(diǎn)上下文）進(jìn)行深入比較。注意，本文將解釋最近宣布的 AspectJ 和 AspectWerkz 項(xiàng)目合并的意義。
面向方面編程（AOP）在 Java? 平臺(tái)上變得日益流行。隨著 AOP 出版物和會(huì)議的增加，這項(xiàng)技術(shù)的工具與實(shí)現(xiàn)越來越多。雖然人們很清楚 AOP 是面向?qū)ο蠹夹g(shù)的補(bǔ)充，但是 Java 開發(fā)人員該如何評估當(dāng)前的 AOP 工具，特別是每項(xiàng)新技術(shù)實(shí)現(xiàn)的優(yōu)劣，這方面則相對不那么清楚。
本文有兩部分，而且本文還是 developerWorks 上一個(gè)新的 AOP 系列的第一篇文章。在本文中，將概述 AOP 工具當(dāng)前的技術(shù)狀況，比較對于該技術(shù)而言最成熟的一些方法：AspectJ、AspectWerkz、JBoss AOP、和 Spring AOP，并對比與每種方法的采用有關(guān)的問題。文中還會(huì)解釋最近宣布的 AspectJ 和 AspectWerkz 項(xiàng)目合并的意義（請參閱參考資料）。
本文無意作為 AOP 的介紹或某個(gè)特定 AOP 實(shí)現(xiàn)的入門讀物。而是將對目前使用最普遍的 AOP 技術(shù)進(jìn)行概述。對每個(gè)工具的語言機(jī)制和工具支持的內(nèi)在優(yōu)劣進(jìn)行探討，將有助于為項(xiàng)目選擇最合適的技術(shù)。這里定義的指標(biāo)還會(huì)讓讀者更加容易地評估即將推出的 AOP 工具和特性。關(guān)于 developerWorks 上介紹 AOP 的最新文章列表，請參閱參考資料。
請注意本文有兩個(gè)部分，為了方便讀者，兩部分同時(shí)發(fā)布。第 1 部分側(cè)重于這 4 個(gè)領(lǐng)先工具各自的 AOP 語言機(jī)制處理技術(shù)，其中包括工具的方面語法（aspect syntax）和切入點(diǎn)的表示、用來聲明方面的機(jī)制范圍等主題。第 2 部分繼續(xù)深入介紹領(lǐng)先的 AOP 實(shí)現(xiàn)如何與現(xiàn)有的開發(fā)環(huán)境、工具和庫進(jìn)行集成。這一部分包括以下主題：方面設(shè)計(jì)器、IDE 插件、可伸縮性和 AOP 工具將來的發(fā)展方向，還包括對最近 AspectJ 和 AspectWerkz 項(xiàng)目合并的關(guān)注。
選擇成熟的工具
AOP 是一項(xiàng)新技術(shù)，所以，并不是現(xiàn)有的所有工具都已經(jīng)成熟到適用于商業(yè)開發(fā)。判斷成熟度的一個(gè)主要因素是用戶的采用程度。在考慮把一項(xiàng)新編程技術(shù)應(yīng)用到商用之前，這項(xiàng)技術(shù)必須從活躍的用戶社區(qū)的反饋中得到強(qiáng)化。表 1 顯示了 aosd.net 上列出的目前可以使用的 AOP 工具（請參閱參考資料）。每個(gè)工具的用戶列表貼子數(shù)量可以表明它的用戶基數(shù)（省略了貼子的實(shí)際數(shù)量，因?yàn)閱为?dú)一個(gè)月的統(tǒng)計(jì)可能給讀者造成誤解）。
表 1. 在 2004 年 11 月 AOP 工具用戶列表中的貼子數(shù)量
|
關(guān)于這個(gè)系列
AOP@Work 系列面對的是在面向方面編程上有些基礎(chǔ)，同時(shí)想擴(kuò)展或加深這方面了解的開發(fā)人員。同 developerWorks 的大多數(shù)文章一樣，這個(gè)系列非常實(shí)用：讀完每篇介紹新技術(shù)的文章，都可以立即將其投入使用。
為這個(gè)系列選擇的每個(gè)作者都是面向方面編程領(lǐng)域的領(lǐng)導(dǎo)或?qū)＜摇ＴS多作者都是系列文章中介紹的項(xiàng)目和工具的參與者。每篇文章都力圖提供一個(gè)中立的評述，以確保這里表達(dá)的觀點(diǎn)的公正與正確。
請就文章的評論或問題分別與這些文章的作者聯(lián)系。要對這個(gè)系列整體進(jìn)行評論，可以與這個(gè)系列的負(fù)責(zé)人 Nicholas Lesiecki 聯(lián)系。
關(guān)于本文
本文并不想突出某一個(gè)工具，而是要用一種批判的、沒有偏見的方式突出每個(gè)工具的優(yōu)勢與不足。雖然作者是 AspectJ 項(xiàng)目的參與者之一，但是在編寫本文的時(shí)候，也咨詢了其他 AOP 工具項(xiàng)目的領(lǐng)導(dǎo)人，以確保公平地展示所討論的技術(shù)。 |
請注意 Spring 的 AOP 部分沒有形成一個(gè)獨(dú)立的下載或用戶社團(tuán)，所以用戶基數(shù)相當(dāng)比例的用戶可能沒有給 Spring AOP 發(fā)貼，而是投在別的主題上了。在 aosd.net 上還列出了 4 個(gè)額外的工具，但是它們要么缺乏用戶討論論壇，要么在 11 月沒有貼子。
AOP 工具雖然沒有列在表中前四位，但它在技術(shù)上可能非常成熟，可是缺乏較大的用戶基數(shù)就意味著它們還沒有經(jīng)受過采納程度測試。雖然在本文編寫的時(shí)候，它們還不適合于商業(yè)開發(fā)，但是這些工具的日后發(fā)展還是值得關(guān)注的。通過上表的比較，還可以看出非 Java 平臺(tái)的 AOP 工具沒有 Java 平臺(tái)的工具成熟，但是應(yīng)當(dāng)注意 .NET 和 C++ 工具的用戶社區(qū)正在成長。
根據(jù)表 1，可以看出，從用戶采用度的角度來說，AspectJ、AspectWerkz、JBoss AOP 和 Spring AOP 是領(lǐng)先的工具。所有這些工具都是適合用于商業(yè)開發(fā)中的開源項(xiàng)目。按字母順序?qū)⑺鼈兣帕腥缦拢ㄋ鼈?V1.0 版本的發(fā)布日期：
- AspectJ —— 2001 年由 Xerox PARC 的 AOP 小組發(fā)行。目前主頁在 eclipse.org 上，由 IBM 支持。版本已經(jīng)更新到 1.2.1。
- AspectWerkz —— 2002 年發(fā)布，由 BEA Systems 支持。版本更新到 2.0RC2。
- JBoss AOP —— 2004 年作為 JBoss 應(yīng)用程序服務(wù)器框架的擴(kuò)展發(fā)布。版本更新到 1.0。
- Spring AOP —— 2004 年作為 Spring 框架的擴(kuò)展發(fā)布。版本更新到 1.1.3.
都是為了連接點(diǎn)
本文介紹的每個(gè) AOP 工具都采用了連接點(diǎn)（join point）模型和機(jī)制，顯式地聲明程序的橫切結(jié)構(gòu)。雖然各個(gè)工具實(shí)現(xiàn)這個(gè)框架的技術(shù)非常相似，但是理解底層機(jī)制對于了解每項(xiàng)技術(shù)的優(yōu)劣是非常重要的。在這一節(jié)中，將回顧 AOP 的連接點(diǎn)模型以及利用連接點(diǎn)模型的語言模型。
支持機(jī)制
AOP 工具的設(shè)計(jì)目標(biāo)是把橫切的問題（例如認(rèn)證和事務(wù)管理）模塊化。在單獨(dú)使用面向?qū)ο蠹夹g(shù)實(shí)現(xiàn)的的時(shí)候，處理這些問題的代碼會(huì)分散在整個(gè)系統(tǒng)中，這種分散造成管理和發(fā)展橫切結(jié)構(gòu)時(shí)出現(xiàn)不必要的困難。與對象提供了一種能夠清楚地捕獲繼承結(jié)構(gòu)的語言機(jī)制類似，AOP 也為橫切問題的良好模塊化提供了同樣的好處。位于每個(gè) AOP 工具核心的是連接點(diǎn)模型，它提供了一種機(jī)制，可以識(shí)別出在哪里發(fā)生了橫切。
連接點(diǎn) 就是主程序和方面相遇的地方。靜態(tài)連接點(diǎn)允許方面定義類上的新成員。動(dòng)態(tài)連接點(diǎn)是方面執(zhí)行與程序執(zhí)行相遇的地方。例如，普通的 Java 程序執(zhí)行方法調(diào)用、字段設(shè)置這樣的連接點(diǎn)。再比如說，請考慮一下這樣一個(gè)問題：對改變 Account 狀態(tài)的活動(dòng)進(jìn)行監(jiān)視，就像在 Ramnivas Laddad 的 AspectJ in Action 一書中討論的那樣（請參閱參考資料）。 圖 1 中的順序圖突出了在 Account 操作上形成的一些動(dòng)態(tài)連接點(diǎn)。
圖 1. 突出了選中的動(dòng)態(tài)連接點(diǎn)的 UML 序列圖
下面的編號(hào)與圖中的編號(hào)對應(yīng)：
- 方法執(zhí)行 連接點(diǎn)，與方法返回之前的生命周期對應(yīng)。
- 控制流程 捕捉在控制流程序列中出現(xiàn)的各個(gè)連接點(diǎn)；在這個(gè)例子中，在
debit() 方法調(diào)用下方的序列描述了在 debit() 調(diào)用中發(fā)生的全部連接點(diǎn)。
- 字段訪問 連接點(diǎn)對應(yīng)著字段的讀和寫；在這個(gè)例子中，在
Account 類上對 name 字段進(jìn)行了賦值。
|
AspectJ 和 AspectWerkz 項(xiàng)目合并
AOP 技術(shù)正在迅速地向前發(fā)展，在本文的第 2 部分突出了領(lǐng)先的 AOP 工具的預(yù)計(jì)的發(fā)布計(jì)劃。有一個(gè)那些思想超前的讀者會(huì)特別感興趣的主題，這就是最近 AspectJ 與 AspectWerkz 項(xiàng)目的合并，這一合并會(huì)給 AOP 的發(fā)展前景帶來重大的變化。一些開發(fā)人員在這些項(xiàng)目上進(jìn)行合作，生產(chǎn) AspectJ 5，這是一種單一工具，融合了這里介紹的 AspectJ 和 AspectWerkz 的語法。
重要的是要注意 AspectWerkz 并沒有正在消失。它將成為編寫 AspectJ 程序的另一種方法，并更名為 @AspectJ 風(fēng)格。在這里可以看到，語法是 AOP 實(shí)現(xiàn)之間的主要區(qū)別因素，而核心的 AOP 機(jī)制通常非常相似。 AspectWerkz 和 AspectJ 的相似性使得這兩種技術(shù)可以聯(lián)合。合并可以在提供方面語法的時(shí)候提供更多的靈活性，同時(shí)保留著關(guān)鍵的好處（例如靜態(tài)類型化和成熟的工具支持）。有關(guān)合并的細(xì)節(jié)以及相關(guān)文檔，可以從參考資料中得到。雖然本文重點(diǎn)放在立刻就可以開始使用的工具上，但是這里概述的指標(biāo)和優(yōu)劣也適用于未來的發(fā)行版（例如 AspectJ 5）。 |
切入點(diǎn)、通知和類型間聲明
AOP 工具提供了識(shí)別連接點(diǎn)集合的機(jī)制，叫作切入點(diǎn)（pointcut）。通知（advice） 機(jī)制指定在程序執(zhí)行過程中遇到匹配的切入點(diǎn)時(shí)應(yīng)當(dāng)采取什么行動(dòng)。另外，類型間聲明（inter-type declaration）（開放類或混合類提供了在現(xiàn)有類型上聲明額外成員的方法。切入點(diǎn)、通知和類型間聲明組合在一起，使 AOP 語言可以清楚地表達(dá)橫切問題。方面 聲明可以在標(biāo)準(zhǔn)的 Java 字段和方法之外包含這三類成員。方面代表一套模塊化良好的橫切結(jié)構(gòu)。如下所示，不同的 AOP 技術(shù)實(shí)現(xiàn)這些方法的技術(shù)各不相同。但是，每種技術(shù)的核心，都是連接點(diǎn)的訪問、編輯、命名和抽象機(jī)制。
切入點(diǎn)可以通過顯式枚舉方式描述連接點(diǎn)集合。應(yīng)當(dāng)用一個(gè)示例指定圖 1 所示的 Account 的利息的三個(gè)方法調(diào)用。雖然枚舉可能很有用，但是用結(jié)構(gòu)化屬性的方式表示連接點(diǎn)通常更方便。這類基于屬性的切入點(diǎn)可以表示一套與“每個(gè)針對 Account 子類型的調(diào)用”匹配的連接點(diǎn)，卻不必強(qiáng)迫程序員枚舉這些子類型。這樣做可以保證向系統(tǒng)添加由 Account 擴(kuò)展的新類時(shí)，新類會(huì)自動(dòng)與切入點(diǎn)匹配。
切入點(diǎn)支持復(fù)合（composition），這就允許把簡單的切入點(diǎn)組合成更復(fù)雜的切入點(diǎn)。例如，可以把所有 Account 調(diào)用的切入點(diǎn)限制在那些針對特定類或控制流程進(jìn)行的調(diào)用中。切入點(diǎn)的命名（naming）機(jī)制提高了可讀性和復(fù)合性。對抽象（abstraction）與具體化（concretization）的支持，可以更加容易地創(chuàng)建通用庫，對于要應(yīng)用庫的特定應(yīng)用程序的切入點(diǎn)來說，這些庫可以獨(dú)立定義。最后，對切入點(diǎn)中公開連接點(diǎn)狀態(tài) 的支持允許對諸如正在執(zhí)行對象和方法參數(shù)之類的訪問事項(xiàng)進(jìn)行商量。
方面比較
如前所述，所有 AOP 工具的底層機(jī)制都是連接點(diǎn)和切入點(diǎn)、通知和類型間聲明的概念。在這些工具中，可以注意到的主要區(qū)別就是方面聲明編寫及應(yīng)用到系統(tǒng)上的方式。這些工具可用以下方法中的一種進(jìn)行方面聲明：使用類似 Java 的代碼、注釋或 XML。對于某些開發(fā)人員來說，熟悉用 Java 語言編程方面的知識(shí)，要比熟悉語言擴(kuò)展技術(shù)的優(yōu)劣更重要，這些內(nèi)容會(huì)在后面的小節(jié)中討論。對于其他人來說，了解注釋和 XML 技術(shù)在集成上的優(yōu)勢，要比痛苦地把切入點(diǎn)當(dāng)作字符串來操作更重要。
在這一節(jié)中，將使用一個(gè)常見的示例指出每個(gè)工具在方面聲明技術(shù)上的差異。請考慮圖 1 所示的 Account 類的授權(quán)策略這樣一個(gè)示例。在面向?qū)ο蟮膶?shí)現(xiàn)中，最常見到的，就是對認(rèn)證的調(diào)用分散在 Account 類的眾多方法以及需要認(rèn)證的其他類中。在 AOP 實(shí)現(xiàn)中，可以明確地用一個(gè)方面捕獲這個(gè)行為，而不必修改操縱帳戶的代碼。不管使用什么工具聲明，這個(gè)方面都需要具備以下特征：
- 一個(gè)切入點(diǎn)，捕捉
banking.Account 類上所有公共方法的執(zhí)行。
- 一種引用正在認(rèn)證的
Account 的方式。
- 通知，在切入點(diǎn)指定的連接點(diǎn)上調(diào)用
Account 的認(rèn)證。
現(xiàn)在，請看這幾個(gè)領(lǐng)先的 AOP 工具各自是如何處理這個(gè)方面的。
AspectJ
Aspect 中的方面聲明類似于 Java 語言中的類聲明，如圖 2 所示。由于 AspectJ 是 Java 語言語法和語義的擴(kuò)展，所以它提供了自己的一套處理方面的關(guān)鍵字。除了包含字段和方法之外，AspectJ 的方面聲明還包含切入點(diǎn)和通知成員。示例中的切入點(diǎn)使用了修飾符（modifier）和通配符（wildcard）模式來表達(dá)“所有公共方法”。對帳戶的訪問，由 pointcut 參數(shù)提供。通知使用這個(gè)參數(shù)，而切入點(diǎn)則用 this(account) 把它綁定。這樣做的效果，就是捕獲了正在執(zhí)行的方法所隸屬 Account 對象。否則，通知的主體與方法的主體相似。通知可以包含認(rèn)證代碼，或者就像在這個(gè)示例中一樣，可以調(diào)用其他方法。
圖 2. AspectJ 的方面
構(gòu)建 AspectJ 程序與構(gòu)建 Java 程序類似，其中包括調(diào)用 AspectJ 的遞增編譯器，構(gòu)建所有的項(xiàng)目源文件，包括普通的 Java 源文件。運(yùn)行 AspectJ 程序也與運(yùn)行 Java 程序一樣，請注意要把 aspectjrt.jar 庫添加到類路徑中。要對在系統(tǒng)中應(yīng)用哪個(gè)方面進(jìn)行配置，必須把它們加入包含列表或從中刪除，包含列表會(huì)傳遞給編譯器，可以通過 IDE 支持傳遞包含列表，如果正在 Ant 環(huán)境或命令行進(jìn)行工作，也可以通過“.lst” 包含文件傳遞。注意，在第 2 部分中，將討論構(gòu)建 AOP 程序的細(xì)節(jié)以及方面設(shè)計(jì)的概念。
AspectWerkz
AspectWerkz 和 AspectJ 之間的重要區(qū)別就是： Authentication 現(xiàn)在是一個(gè)普通的 Java 類，而不是一個(gè)方面。AspectWerkz、JBoss AOP 和 Spring AOP 都在沒有改變 Java 語言語法的情況下加入了方面語義。AspectWerkz 提供了兩種進(jìn)行 AOP 聲明的途徑。最常用的是注釋，注釋可以采用圖 3 中的 Java V5.0 風(fēng)格，也可以為了與 J2SE V1.4 兼容采用 Javadoc 風(fēng)格。AspectWerkz 還支持另外一種基于 XML 的方面聲明風(fēng)格。XML 風(fēng)格與下面介紹的 JBoss AOP 的風(fēng)格類似，把方面聲明放在單獨(dú)的 XML 文件中。
請注意通知就是普通的方法聲明。按照約定，它被當(dāng)作不同類型的方法聲明，因?yàn)椴粦?yīng)當(dāng)顯式地調(diào)用它，而是應(yīng)該在滿足特定切入點(diǎn)時(shí)自動(dòng)運(yùn)行它。AspectWerkz 的切入點(diǎn)聲明是附加到切入點(diǎn)“方法”的字符串值，也可以在 XML 文件中獨(dú)立存在。所以，沒有切入點(diǎn)的 import 機(jī)制，所有的類型引用必須完全規(guī)范。對正在運(yùn)行的 Account 對象的訪問技術(shù)與 AspectJ 相同。請注意，規(guī)劃的 @AspectJ 語法看起來與 AspectWerkz 注釋的語法非常相似。
圖 3. AspectWerkz 的方面
構(gòu)建 AspectWerkz 程序會(huì)涉及一個(gè)標(biāo)準(zhǔn)的 Java 構(gòu)建，然后會(huì)涉及到后處理。要運(yùn)行 AspectWerkz 程序，必須把 AspectWerkz 庫放在類路徑中。在使用不可插入的方面的情況下，由 aop.xml 文件配置系統(tǒng)中一些方面的包含情況。
JBoss AOP
JBoss AOP 基于 XML 的方面來聲明風(fēng)格，如圖 4 所示。JBoss 也支持與圖 3 所示相似的注釋風(fēng)格。在 XML 風(fēng)格中，方面、切入點(diǎn)和通知聲明都以 XML 形式表示的。通知的實(shí)現(xiàn)，用的是普通的 Java 方法，由 JBoss AOP 框架調(diào)用。切入點(diǎn)和切入點(diǎn)到通知的綁定都在方面中用 XML 注釋聲明。JBoss 沒有顯式地綁定 Account 參數(shù)，而是提供了對當(dāng)前正在執(zhí)行的對象的反射訪問，因此需要把類型轉(zhuǎn)換到對應(yīng)的類型。注意，即將發(fā)布的 JBoss 會(huì)提供一些靜態(tài)類型的切入點(diǎn)參數(shù)來解決這一問題。
圖 4. JBoss AOP 的方面
用 JBoss 構(gòu)建方面只包括普通的 Java 構(gòu)建。JBoss AOP 的運(yùn)行時(shí)截取框架（interception framework）負(fù)責(zé)管理切入點(diǎn)匹配和通知調(diào)用。需要對啟動(dòng)和類路徑做一些配置，但是 JBoss AOP 的 IDE 插件替用戶做了這些工作。方面在 jboss-aop.xml 文件中配置。
Spring AOP
查看圖 5 中的 Spring AOP 示例時(shí)，可以注意到其中的 XML 比前面介紹的技術(shù)多。與 JBoss AOP 類似，Spring 的通知實(shí)現(xiàn)是帶有特殊參數(shù)的 Java 方法，由 Spring 框架調(diào)用。XML 描述 accountBean，Spring 框架通過它訪問 Account 對象，包括通知使用的攔截器 advisor 及其匹配模式，還有應(yīng)用到模式的向前（before） 通知。
圖 5. Spring AOP 的方面
Spring AOP 的技術(shù)雖然提供了更加精細(xì)的配置，但在將它用于 XML 時(shí)，它與 JBoss AOP 非常類似。構(gòu)建、運(yùn)行和配置 Spring AOP 方面的過程與 JBoss AOP 相同，但 Spring AOP 依賴的是 Spring 框架方便的、最小化的運(yùn)行時(shí)配置，所以不需要獨(dú)立的啟動(dòng)器。請注意，使用這個(gè)技術(shù)，只能通知從 Spring 框架檢索出的對象。
語法差異
正如上面的圖所展示的，AOP 工具之間的關(guān)鍵差異就是處理方面聲明的方式。AspectJ 是 Java 語言的擴(kuò)展，用它可以完全在代碼中對方面進(jìn)行聲明。AspectWerkz 和 JBoss AOP 支持用方面元數(shù)據(jù)對 Java 代碼進(jìn)行注釋，或者在獨(dú)立的 XML 文件中對方面進(jìn)行聲明。在 Spring AOP 中，則完全用 XML 對方面進(jìn)行聲明。所以，在三種不同的技術(shù)中，對方面進(jìn)行編程的感覺可能非常不同。用 AspectJ 的代碼風(fēng)格，方面和切入點(diǎn)聲明感覺起來就像 Java 代碼。而用 JBoss AOP 或 AspectWerkz 的注釋風(fēng)格，感覺起來就像在現(xiàn)有 Java 元素上做的附加標(biāo)簽。而用 Spring AOP 風(fēng)格，以及 AspectWerkz 和 JBoss AOP 的 XML 風(fēng)格 時(shí)，感覺就像使用獨(dú)立的聲明性 XML 語言。
每種技術(shù)都有它的優(yōu)勢，具體要由使用者決定哪個(gè)更適合需求。所以在這一節(jié)，將簡要地討論一些能夠有助于進(jìn)行決策的要點(diǎn)。
自己的風(fēng)格是什么？
不管選擇哪個(gè) AOP 工具，使用通知主體時(shí)只涉及到使用 Java 代碼。如果需要修改切入點(diǎn)，那么區(qū)別是非常透明的。在使用 XML 風(fēng)格時(shí)（就像在 Spring AOP 中），修改切入點(diǎn)包括：從通知找到 XML 文件中對應(yīng)的切入點(diǎn)聲明。從正面來說，這項(xiàng)技術(shù)把切入點(diǎn)和方面配置的工作全都局限于本地，但是如果要編輯許多通知和切入點(diǎn)，而且要在 Java 和 XML 之間重復(fù)地翻來覆去，那么這項(xiàng)工作就會(huì)變得很繁瑣。
如果使用 AspectWerkz 或 JBoss AOP 提供的注釋風(fēng)格，那么就可以把切入點(diǎn)的表達(dá)值從 XML 轉(zhuǎn)移到 Java 成員的注釋。這樣可以更容易地并發(fā)處理通知體和切入點(diǎn)。如果選擇了 AspectJ 的代碼風(fēng)格，那么就會(huì)發(fā)現(xiàn)處理切入點(diǎn)感覺就像處理代碼，而不像是處理非結(jié)構(gòu)化的字符串值。從 Java 代碼能得到的一切（例如“import”語句），都可以用于切入點(diǎn)。對比之下，如果用 AspectWerkz、JBoss AOP 和 Spring AOP 的 XML 和注釋風(fēng)格，總是需要在規(guī)范切入點(diǎn)中的類型引用。
簡潔還是繁瑣？
方面聲明的風(fēng)格對每個(gè)工具中使用的方面有很大的影響。例如，支持在 XML 中聲明方面的工具，也支持在同一 XML 文件中對方面應(yīng)用到系統(tǒng)的方式進(jìn)行配置。在前面的小節(jié)中，只展示了切入點(diǎn)和方面聲明，但是類型間聲明同樣受到風(fēng)格選擇的影響。在 AspectJ 中，類型間方法聲明看起來就像正常的方法聲明，引用的技術(shù)也一樣。而在其他技術(shù)中，則要指定一個(gè)類，擴(kuò)展額外的混合類并繼承那些額外的成員，通過注釋或 XML 添加新方法。注意，目前 AspectJ 是惟一提供使用切入點(diǎn)的靜態(tài)強(qiáng)制機(jī)制的工具。表 2 比較了這些工具對 AOP 語法的關(guān)鍵元素的處理技術(shù)。
表 2. 比較領(lǐng)先的 AOP 工具中的語法
顯然，從圖 2-5 的方面聲明來看，代碼風(fēng)格是處理 AOP 聲明最簡潔的技術(shù)。它不需要對通知命名，也不需要顯式地調(diào)用通知。代碼風(fēng)格不需要顯式地把通知綁定到切入點(diǎn)（就像 XML 風(fēng)格那樣），也不需要把通知綁定到 return 語句（這是 AspectWerkz 的切入點(diǎn)“方法”所需要的）。對于可以在 圖 3 和 圖 4 的 XML 中看到的復(fù)雜設(shè)計(jì)，AspectJ 對 Java 語言進(jìn)行的語法擴(kuò)展允許直接表示這些設(shè)計(jì)。用 AspectJ 編寫方面，感覺起來更像是編寫 Java 代碼，避免了冗余的鍵入，因此出錯(cuò)也就更少。從不好的一面來說，Java 的語法擴(kuò)展代價(jià)巨大，而注釋和 XML 風(fēng)格有它們獨(dú)特的優(yōu)勢。最明顯的就是 XML 風(fēng)格可以控制切入點(diǎn)和通知的綁定。這對于擴(kuò)展和配置方面非常有益，在下面一節(jié)中將討論這點(diǎn)以及不同風(fēng)格帶來的其他優(yōu)缺點(diǎn)。
代碼風(fēng)格與注釋和 XML 的比較
那么，應(yīng)當(dāng)采用代碼風(fēng)格，還是用注釋或 XML 聲明方面呢？以下是基于 AspectJ 的 Java 代碼的一些技術(shù)的優(yōu)缺點(diǎn)總結(jié)：
- 簡明語法充分利用對 Java 代碼的熟悉，減少鍵入錯(cuò)誤，使錯(cuò)誤更少。
- 切入點(diǎn)是一級(jí)實(shí)體，因此更容易對它們進(jìn)行處理。
- 對于許多開發(fā)人員，用 XML 進(jìn)行聲明性編程要比用 Java 語言擴(kuò)展更熟悉。
- 通知到切入點(diǎn)的綁定不能由開發(fā)人員控制。
如果這個(gè)小結(jié)仍然無法縮小決策范圍，那么不要擔(dān)心。除了用每種風(fēng)格編寫這些方面的感覺之外，還有更多需要考慮的東西。當(dāng)在下一節(jié)中查看語義的時(shí)候，語法決策還會(huì)出現(xiàn)，而且也會(huì)影響在第 2 部分中討論的工具支持。
語義的相似性
雖然工具的方面聲明風(fēng)格之間存在主要的語法差異，但是核心的 AOP 語義是類似的。每個(gè)工具都有完全相同的連接點(diǎn)模型的概念，都把連接點(diǎn)作為 Java 程序中的關(guān)鍵點(diǎn)，把切入點(diǎn)作為匹配連接點(diǎn)的機(jī)制，把通知作為指定連接點(diǎn)匹配時(shí)執(zhí)行操作的機(jī)制。
表 3 和 表 4 總結(jié)了每種技術(shù)的語義。您可以注意到，命令規(guī)范上有許多微小的差異和變化，但是各種技術(shù)最終聚合在相同的核心概念上。這種聚合有很大的好處，因?yàn)檫@意味著學(xué)習(xí)曲線很容易從一項(xiàng) AOP 技術(shù)轉(zhuǎn)移到另外一項(xiàng) AOP 技術(shù)。剩下來要考慮的就是每種技術(shù)的差異所帶來的優(yōu)劣了。
回到連接點(diǎn)
一個(gè) AOP 工具連接點(diǎn)模型的表達(dá)方式?jīng)Q定了可用的連接點(diǎn)粒度，以及連接點(diǎn)如何匹配。每個(gè) AOP 工具都提供了大量用于連接點(diǎn)匹配的原生切入點(diǎn)。有些原生切入點(diǎn)只與特定類型的連接點(diǎn)匹配（例如，方法執(zhí)行）。其他切入點(diǎn)能夠根據(jù)連接點(diǎn)的公共屬性（例如，在某個(gè)控制流程中的所有連接點(diǎn)）匹配任何類型的連接點(diǎn)。連接點(diǎn)的類型以及它們特定的切入點(diǎn)，可以分成以下幾組：
- 調(diào)用（Invocation）—— 調(diào)用或執(zhí)行方法和其他代碼元素時(shí)的點(diǎn)。
- 初始化（Initialization）—— 初始化類和對象時(shí)的點(diǎn)。
- 訪問（Access）—— 讀寫某些字段時(shí)的點(diǎn)。
- 異常處理（Exception handling）—— 拋出和處理異常與錯(cuò)誤時(shí)的點(diǎn)。
另外，也支持以下沒有類型的切入點(diǎn)分類：
- 控制流程（Control flow）—— 在某個(gè)流程控制流程中的連接點(diǎn)。
- 包含（Containment）—— 與包含在某個(gè)類或方法中的代碼位置對應(yīng)的連接點(diǎn)。
- 條件（Conditional）—— 特定預(yù)測為真的連接點(diǎn)。
如表 3 所示，每個(gè)工具實(shí)現(xiàn)連接點(diǎn)模型的方式，以及它們用來匹配連接點(diǎn)的原生切入點(diǎn)，都略有差異。注意，在某些情況下（在括號(hào)中表示），連接點(diǎn)不用切入點(diǎn)標(biāo)識(shí)。
表 3. 連接點(diǎn)和用來匹配連接點(diǎn)的原生切入點(diǎn)
要富于表現(xiàn)力還是要簡單？
在這里主要的優(yōu)劣在于富于表現(xiàn)力和簡單性的比較。更加完整和精細(xì)的切入點(diǎn)集合允許通過方面訪問程序執(zhí)行中更多有趣的點(diǎn)。例如，與持久性有關(guān)的方面可能需要訪問對象的初始化連接點(diǎn)。但是這類完整性也會(huì)帶來額外的復(fù)雜性和更陡峭的學(xué)習(xí)曲線。許多 Java 程序員并不區(qū)分調(diào)用和執(zhí)行，而且沒有幾個(gè)人需要理解初始化的微妙之處。而且許多常用的方面被當(dāng)作是輔助性的，所以是否有表現(xiàn)力與應(yīng)用程序的功能并沒有緊密耦合。在常用的輔助性方面，例如監(jiān)視和日志，通常只利用了粗粒度的切入點(diǎn)（例如方法執(zhí)行）。從反面來看，更廣泛的切入點(diǎn)集合確實(shí)具備量入為出的屬性，因?yàn)榍腥朦c(diǎn)可以邊用邊學(xué)。如果不想用切入點(diǎn)制作程序，那么會(huì)造成面向?qū)ο蟠a的強(qiáng)制重構(gòu)，例如：以 init() 方法的形式公開類的初始化。
AspectJ 和 AspectWerkz 的連接點(diǎn)模型差不多完全融合，而且已經(jīng)成為最近的合并的關(guān)鍵促進(jìn)者之一。JBoss AOP 模型幾乎同樣有表現(xiàn)力，只是為了簡單性而遺漏了一些不太常用的連接點(diǎn)。一個(gè)明顯的差異是：在 JBoss Aop 中，不能把控制流程表示成“在這個(gè)切入點(diǎn)的執(zhí)行之下的所有連接點(diǎn)”。相反，程序員需要手動(dòng)列出調(diào)用堆棧中的每個(gè)調(diào)用。
Spring AOP 采用了不同的技術(shù)，目的是限制它的連接點(diǎn)模型的表現(xiàn)力。這使它特別容易采用，而且對于一些粗粒度的橫切很有用。即將發(fā)行的版本將與 AspectJ 集成，提供與精細(xì)橫切機(jī)制的互操作性。
連接點(diǎn)模型的表現(xiàn)力與簡單性的比較
一些項(xiàng)目可以從更有表現(xiàn)力的連接點(diǎn)模型（例如 AspectWerkz、AspectJ 和 JBoss AOP 提供的）獲益，所以最好還是采用 Spring AOP 粗粒度的方便性？以下是更有表現(xiàn)力的模型固有優(yōu)缺點(diǎn)的一個(gè)總結(jié)，多考慮一下這些方面會(huì)對您有所幫助：
- 了解更多知識(shí) 。
- 對于粗粒度的橫切和輔助性方面，只需要很少的切入點(diǎn)。
- 沒有精細(xì)的切入點(diǎn)，許多方面就不能表達(dá)。
- 使用新切入點(diǎn)的學(xué)習(xí)曲線是隨用隨學(xué)。
語言機(jī)制
我將用每種技術(shù)語言機(jī)制的詳細(xì)對比結(jié)束 AOP 工具比較的第一部分的討論。表 4 是 4 個(gè)工具的 AOP 語言的概括。下面討論了最明顯的區(qū)別。
表 4. 領(lǐng)先的 AOP 工具的語義概括
切入點(diǎn)匹配和復(fù)合：AspectJ、AspectWerkz 和 JBoss AOP 提供了類似的類型模式支持。它們?nèi)齻€(gè)都允許簽名方面的匹配，對于 Java 5 應(yīng)用程序來說，這些匹配包括注釋和泛型。AspectJ 和 AspectWerkz 提供了一種簡潔的引用多個(gè)類型的技術(shù)（例如 Account+ 表示帳戶的所有子類型）。所有的工具都支持通配符匹配。Spring AOP 還提供了對正則表達(dá)式的支持。雖然這看起來可能是一個(gè)強(qiáng)大的優(yōu)勢，但還是要指出其他技術(shù)已經(jīng)選擇了放棄正則表達(dá)式，好讓切入點(diǎn)讀起來不是太難，同時(shí)不會(huì)存在潛在的損害。切入點(diǎn)復(fù)合操作符基本上都是相同的。Spring AOP 不提供“非”操作，這個(gè)操作通常與沒有在 Spring AOP 連接點(diǎn)模型的容器（containment）連接點(diǎn)結(jié)合使用。
通知形式：AspectJ 支持比其他技術(shù)更多的通知形式，而 JBoss AOP 只支持一種通知形式。每種通知形式都可以表達(dá)成 around 通知，所以 JBoss 的技術(shù)是無限的，而且它確實(shí)提供了額外的簡單性。不好的一面是它損失了簡潔性，這一點(diǎn)可以從需要進(jìn)行額外的調(diào)用才能繼續(xù)執(zhí)行原來的方法調(diào)用（如 圖 4 所示）看得出來，而如果用 before 進(jìn)行通知，這一點(diǎn)就是不必要的。還請注意，強(qiáng)迫通知去遵守普通的 Java 規(guī)則（就像注釋和 XML 風(fēng)格做的那樣），在一些情況下容易出問題，因?yàn)檫@些規(guī)則是為方法設(shè)計(jì)的。AspectJ 擁有把被通知方法的異常“軟化”的能力，這很有用，但是不符合方法異常檢測的標(biāo)準(zhǔn)語義。
連接點(diǎn)上下文：在 AspectJ 和 AspectWerkz 中，通過指定和綁定切入點(diǎn)參數(shù)訪問動(dòng)態(tài)連接點(diǎn)的狀態(tài)，類似于在 Java 語言中聲明方法參數(shù)的技術(shù)（請參閱圖 2 和 圖 3）。這為連接點(diǎn)上下文提供了靜態(tài)類型化的好處。JBoss AOP 和 Spring AOP 反射性地訪問連接點(diǎn)的狀態(tài)，這消除了在切入點(diǎn)表達(dá)式中參數(shù)綁定的復(fù)雜性，代價(jià)是參數(shù)靜態(tài)類型化。Java 程序員習(xí)慣了方法參數(shù)靜態(tài)類型化帶來的好處，同時(shí)還可以從切入點(diǎn)參數(shù)的靜態(tài)類型化得到同樣的好處。所以，在 JBoss AOP 最近的發(fā)行版本中，有提供靜態(tài)類型化的“args” 的計(jì)劃。
實(shí)例化：在所有的工具中，方面的實(shí)例化是由 per 子句控制的。正如所料，Spring AOP 的實(shí)例化模型更簡單。對于額外的實(shí)例化機(jī)制的支持，則意味著可以把方面編寫成只能應(yīng)用于特定的動(dòng)態(tài)上下文環(huán)境中，不用編寫代碼保存這個(gè)上下文并測試其他方面是否該應(yīng)用這個(gè)方面。主要的區(qū)別因素是 AspectJ 支持在每個(gè)控制流程進(jìn)行方面初始化，AspectWerkz 支持每個(gè)線程的初始化，而 JBoss 則支持每個(gè)連接點(diǎn)的初始化。哪種最有用則取決于具體的需求。
擴(kuò)展性：方面的擴(kuò)展性支持庫方面的部署，這樣可以在日后為特定程序而將這些庫方面具體化。例如，一個(gè)方面庫可以提供應(yīng)用程序監(jiān)視需要的全部邏輯和基礎(chǔ)設(shè)施。但是，要采用某個(gè)特定項(xiàng)目的庫，那么庫使用的切入點(diǎn)必須擴(kuò)展成應(yīng)用程序特定的連接點(diǎn)。AspectJ 用抽象方面支持?jǐn)U展性，抽象方面包含抽象的切入點(diǎn)和具體的通知。擴(kuò)展抽象方面的子方面必須具體化切入點(diǎn)。AspectWerkz 和 JBoss AOP 使用了完全不同的技術(shù)，沒有使用抽象切入點(diǎn)機(jī)制。擴(kuò)展是通過生成方面的子類、并在 XML 中或通過注釋定義新的通知綁定而實(shí)現(xiàn)的。切入點(diǎn)到通知的顯式綁定為 AspectWerkz 和 JBoss AOP 提供了顯著優(yōu)勢，從而可以很容易地把方面擴(kuò)展到新系統(tǒng)，無需要生成子類。方面庫的使用數(shù)據(jù)正在日益增多，這些將決定與其他技術(shù)使用的 Java 風(fēng)格的繼承和切入點(diǎn)綁定相比，AspectJ 特殊的 AOP 繼承形式是更好還是更差。
每項(xiàng)技術(shù)在處理 AOP 的語言機(jī)制時(shí)，都提供了自己獨(dú)特的優(yōu)缺點(diǎn)。用一個(gè)簡單的列表來總結(jié)這些優(yōu)缺點(diǎn)是不可能的，因?yàn)閷τ诓煌捻?xiàng)目，每項(xiàng)技術(shù)的好處是各不相同的。但是，以上信息為選擇工具或者遇到關(guān)鍵問題時(shí)尋找替代品提供了指南。
結(jié)束語
為項(xiàng)目選擇一個(gè) AOP 工具所面臨的難題在于比較每種工具的優(yōu)劣，同時(shí)不要讓自己迷失其中。AOP工具比較的第一部分強(qiáng)調(diào)了 4 種領(lǐng)先的 AOP 技術(shù)的核心機(jī)制，并對比了它們的相似與不同之處。
如果本文是在十年之前報(bào)道一項(xiàng)新的模塊化技術(shù)，那么我們可能就此打住，開始用自己選擇的風(fēng)格來編寫方面 —— 可能是在命令行用 Emacs 或其他文本編輯器構(gòu)建。但是今天，如果沒有深入研究一項(xiàng)新技術(shù)如何與現(xiàn)有的開發(fā)環(huán)境和其他工具集成，人們是不會(huì)輕易地考慮采用它的。
所以，本文的第二部分把重點(diǎn)放在集成因素對 AOP工具選擇的影響。在其他因素之中，將討論每個(gè)工具如何處理方面的編譯與設(shè)計(jì)，以及如何依據(jù) IDE 集成與工具支持將它們都組合在一起。我還會(huì)比較這些工具的基本特性，看看它們背后到底是什么，包括進(jìn)一步探討 AspectJ 與 AspectWerkz 項(xiàng)目合并之后我們可以期盼從中得到什么。
參考資料
關(guān)于作者
Mik Kersten 是一流的面向方面的編程專家，也是 AspectJ 和 AJDT eclipse.org 項(xiàng)目的參與者。作為 Xerox PARC 的研究科學(xué)家，他為 AspectJ 構(gòu)建了 IDE 支持。他正在不列顛哥倫比亞大學(xué)攻讀博士學(xué)位，他的主要工作是使 IDE 更加面向方面。他也向構(gòu)建開發(fā)工具的公司提供咨詢，幫助公司利用、支持面向方面的編程技術(shù)。 |
|