運用Jakarta Struts的七大實戰心法

運用Jakarta Struts的七大實戰心法[@more@]　　編者按：當作者 Chuck Cavaness（著有《Programming Jakarta Struts》一書）所在的網路公司決定採用Struts框架之後，Chuck曾經花費了好幾個月來研究如何用它來構建公司的應用系統。本文敘述的正是作者在運用Struts過程中來之不易的若干經驗和心得。如果你是個負責透過jsp和servlet開發Web應用的Java程式設計師，並且也正在考慮採用基於Struts的構建方法的話，那麼你會在這裡發現很多頗有見地同時也很有價值的資訊。

　　1. 只在必要的時候才考慮擴充套件Struts框架

　　一個好的framework有很多優點，首先，它必須能夠滿足使用者的可預見的需求。為此 Struts為Web 應用提供了一個通用的架構，這樣開發人員可以把精力集中在如何解決實際業務問題上。其次，一個好的framework還必須能夠在適當的地方提供擴充套件介面，以便應用程式能擴充套件該框架來更好的適應使用者的實際需要。

　　如果Struts framework在任何場合，任何專案中都能很好的滿足需求，那真是太棒了。但是實際上，沒有一個框架聲稱能做到這一點。一定會有一些特定的應用需求是框架的開發者們無法預見到的。因此，最好的辦法就是提供足夠的擴充套件介面，使得開發工程師能夠調整struts來更好的符合他們的特殊要求。

　　在Struts framework中有很多地方可供擴充套件和定製。幾乎所有的配置類都能被替換為某個使用者定製的版本，這隻要簡單的修改一下Struts的配置檔案就可以做到。

　　其他元件如ActionServlet和 RequestProcessor 也能用自定義的版本代替. 甚至連Struts 1.1裡才有的新特性也是按照擴充套件的原則來設計的。例如，在異常處理機制中就允許使用者定製異常處理的控制程式碼，以便更好的對應用系統發生的錯誤做出響應。

　　作為框架的這種可調整特性在它更適合你的應用的同時也在很大的程度上影響了專案開發的效果。首先，由於您的應用是基於一個現有的成熟的、穩定的framework如Struts，測試過程中發現的錯誤數量將會大大減少，同時也能縮短開發時間和減少資源的投入。因為你不再需要投入開發力量用於編寫基礎框架的程式碼了。

　　然而, 實現更多的功能是要花費更大的代價的。我們必須小心避免不必要的濫用擴充套件效能， Struts是由核心包加上很多工具包構成的，它們已經提供了很多已經實現的功能。因此不要盲目的擴充套件Struts框架，要先確定能不能採用其他方法使用現有的功能來實現。 在決定編寫擴充套件程式碼前務必要確認Struts的確沒有實現你要的功能。否則重複的功能會導致混亂將來還得花費額外的精力清除它。

　　2. 使用異常處理宣告

　　要定義應用程式的邏輯流程，成熟的經驗是推薦在程式碼之外，用配置的方法來實現，而不是寫死在程式程式碼中的。在J2EE中，這樣的例子比比皆是。從實現EJB的安全性和事務性行為到描述JMS訊息和目的地之間的關係，很多執行時的處理流程都是可以在程式之外定義的。

　　Struts 建立者從一開始就採用這種方法，透過配置Struts的配置檔案來定製應用系統執行時的各個方面。這一點在版本1.1的新特性上得到延續，包括新的異常處理功能。在Struts framework以前的版本中，開發人員不得不自己處理Struts應用中發生的錯誤情況。在最新的版本中，情況大大的改觀了，Struts Framework提供了內建的一個稱為 ExceptionHandler 的類， 用於系統預設處理action類執行中產生的錯誤。這也是在上一個技巧中我們提到的framework許多可擴充套件介面之一。

　　Struts預設的 ExceptionHandler類會生成一個ActionError物件並儲存在適當的範圍（scope）物件中。這樣就允許JSP頁面使用錯誤類來提醒使用者出現什麼問題。如果你認為這不能滿足你的需求，那麼可以很方便的實現你自己的ExcepionHandler類。

　　具體定製異常處理的方法和機制

　　要定製自己的異常處理機制，第一步是繼承org.apache.struts.action.ExceptionHandler類。這個類有2個方法可以覆蓋，一個是excute()另外一個是storeException(). 在多數情況下，只需要覆蓋其中的excute()方法。下面是ExceptionHandler類的excute()方法宣告：
　　正如你看到的，該方法有好幾個引數，其中包括原始的異常。方法返回一個ActionForward物件，用於異常處理結束後將controller類帶到請求必須轉發的地方去。

　　當然您可以實現任何處理，但一般而言，我們必須檢查丟擲的異常,並針對該型別的異常進行特定的處理。預設的，系統的異常處理功能是建立一個出錯資訊，同時把請求轉發到配置檔案中指定的地方去。 定製異常處理的一個常見的例子是處理巢狀異常。假設該異常包含有巢狀異常，這些巢狀異常又包含了其他異常，因此我們必須覆蓋原來的execute()方法，對每個異常編寫出錯資訊。

　　一旦你建立了自己的ExceptionHandler 類，就應該在Struts配置檔案中的部分宣告這個類，以便讓Struts知道改用你自定義的異常處理取代預設的異常處理.

　　可以配置你自己的ExceptionHandler 類是用於Action Mapping特定的部分還是所有的Action物件。如果是用於Action Mapping特定的部分就在元素中配置。如果想讓這個類可用於所有的Action物件,可以在 元素中指定。例如，假設我們建立了異常處理類CustomizedExceptionHandler用於所有的Action類, 元素定義如下所示：

　　在元素中可以對很多屬性進行設定。在本文中，最重要的屬性莫過於handler屬性, handler屬性的值就是自定義的繼承了ExceptionHandler類的子類的全名。 假如該屬性沒有定義，Struts會採用自己的預設值。當然，其他的屬性也很重要，但如果想覆蓋預設的異常處理的話，handler無疑是最重要的屬性。

　　最後必須指出的一點是，你可以有不同的異常處理類來處理不同的異常。在上面的例子中，CustomizedExceptionHandler用來處理任何java.lang.Exception的子類. 其實，你也可以定義多個異常處理類，每一個專門處理不同的異常樹。下面的XML片斷解釋瞭如何配置以實現這一點。

　　在這裡，一旦有異常丟擲，struts framework將試圖在配置檔案中找到ExceptionHandler，如果沒有找到，那麼struts將沿著該異常的父類鏈一層層往上找直到發現匹配的為止。因此，我們可以定義一個層次型的異常處理關係結構，在配置檔案中已經體現了這一點。

　　3. 使用應用模組（Application Modules）

　　Struts 1.1的一個新特性是應用模組的概念。應用模組允許將單個Struts應用劃分成幾個模組，每個模組有自己的Struts配置檔案，JSP頁面，Action等等。這個新特性是為了解決大中型的開發隊伍抱怨最多的一個問題，即為了更好的支援並行開發允許多個配置檔案而不是單個配置檔案。

　　注：在早期的beta版本中，該特性被稱為子應用（sub-applications），最近的改名目的是為了更多地反映它們在邏輯上的分工。

　　顯然，當很多開發人員一起參加一個專案時，單個的Struts配置檔案很容易引起資源衝突。應用模組允許Struts按照功能要求進行劃分，許多情況已經證明這樣更貼近實際。例如，假設我們要開發一個典型的商店應用程式。可以將組成部分劃分成模組比如catalog（商品目錄）, customer（顧客）, customer service（顧客服務）, order（訂單）等。每個模組可以分佈到不同的目錄下，這樣各部分的資源很容易定位，有助於開發和部署。圖1 顯示了該應用的目錄結構。

　　圖 1. 一個典型的商店應用程式的目錄結構
　　

　　注：如果你無需將專案劃分成多個模組，Struts框架支援一個預設的應用模組。這就使得應用程式也可以在1.0版本下建立，具有可移植性，因為應用程式會自動作為預設的應用模組。

　　為了使用多應用模組功能，必須執行以下幾個準備步驟：

　　• 為每個應用模組建立獨立的Struts配置檔案。

　　• 配置Web 部署描述符 Web.xml檔案。

　　• 使用org.apache.struts.actions.SwitchAction 來實現程式在模組之間的跳轉.

　　建立獨立的Struts配置檔案

　　每個Struts應用模組必須擁有自己的配置檔案。允許建立自己的獨立於其他模組的Action，ActionForm，異常處理甚至更多。

　　繼續以上面的商店應用程式為例，我們可以建立以下的配置檔案：一個檔名為struts-config-catalog.xml，包含catalog（商品目錄）、items(商品清單)、和其它與庫存相關的功能的配置資訊；另一個檔名為struts- config-order.xml, 包含對order（訂單）和order tracking（訂單跟蹤）的設定。第三個配置檔案是struts-config.xml,其中含有屬於預設的應用模組中的一般性的功能。