12個最重要的J2EE最佳實踐

12個最重要的J2EE最佳實踐[@more@]　　最佳實踐

　　1、始終使用 MVC 框架。
　　2、在每一層都應用自動單元測試和測試管理。
　　3、按照規範來進行開發，而不是按照應用伺服器來進行開發。
　　4、從一開始就計劃使用 J2EE 安全性。
　　5、建立您所知道的。
　　6、當使用 EJB 元件時，始終使用會話 Facades。
　　7、使用無狀態會話 bean，而不是有狀態會話 bean.
　　8、使用容器管理的事務。
　　9、將 JSP 作為表示層的首選。
　　10、當使用 HttpSession 時，儘量只將當前事務所需要的狀態儲存其中，其他內容不要儲存在 HttpSession 中。
　　11、在 WebSphere 中，啟動動態快取，並使用 WebSphere servlet 快取機制。
　　12、為了提高程式設計師的工作效率，將 CMP 實體 bean 作為 O/R 對映的首選解決方案。

　　1. 始終使用 MVC 框架。

　　MVC 框架可以將業務邏輯（Java beans 和 EJB 元件)、控制器邏輯（Servlets/Struts 動作）、表示層（JSP、XML/XSLT）清晰地分離開來。良好的分層可以帶來許多好處。

　　MVC 框架對於成功使用 J2EE 是如此重要，以致沒有其他最佳實踐可以與其相提並論。模型-檢視-控制器（MVC）是設計 J2EE 應用程式的基礎。MVC 將您的程式程式碼簡單地劃分下面幾個部分：

　　·負責業務邏輯的程式碼（即模型——通常使用 EJB 或者普通的 Java 物件來實現）。
　　·負責使用者介面顯示的程式碼（即檢視——通常透過 JSP 及標記庫來實現，有時也使用 XML 和 XSLT 來實現）。
　　·負責應用程式流程的程式碼（即控制器——通常使用 Java Servlet 或像 Struts 控制器這樣的類來實現）。

　　如果您不遵循基本的 MVC 框架，在開發過程中就會出現許多的問題。最常見的問題就是在檢視部分新增了太多的成分，例如，可能存在使用 JSP 標記來執行資料庫訪問，或者在 JSP 中進行應用程式的流程控制，這在小規模的應用程式中是比較常見的，但是，隨著後期的開發，這樣做將會帶來問題，因為 JSP 逐步變得越來越難以維護和除錯。

　　類似地，我們也經常看到將檢視層構建到業務邏輯的情況。例如，一個常見的問題就是將在構建檢視時使用的 XML 解析技術直接應用到業務層。業務層應該對業務物件——而不是繫結到檢視的特定資料表示進行操作。

　　然而，只是具有合適的元件並不一定意味著可以使您的應用程式得到合適的分層。我們常常見到一些應用程式包含 servlet、JSP 和 EJB 元件所有這三項，然而，其主要的業務邏輯卻是在 servlet 層實現的，或者應用程式導航是在 JSP 中處理的。您必須進行嚴格的程式碼檢查並重構您的程式碼，以確保應用程式的業務邏輯只在模型層（Model layer）進行處理，應用程式導航只透過控制器層（Controller layer）進行處理，而您的檢視（Views）只是將傳遞過來的模型物件以 HTML 及 JavaScript 的形式表示出來。

　　2. 在應用程式的每一層都使用自動單元測試和測試管理。

　　不要只是測試您的圖形使用者介面（GUI)。分層的測試使測試及維護工作變得極其簡單。

　　在過去的幾年中，在方法學領域有了相當大的革新，例如新出現的被稱為 Agile（例如 SCRUM [Schwaber] 和極限程式設計 [Beck1]）的輕量級方法現在已經得到了很普遍的應用。幾乎所有的這些方法中的一個共同的特徵是它們都提倡使用自動的測試工具，這些工具可以幫助開發人員用更少的時間進行迴歸測試 (regression testing)，並可以幫助他們避免由於不充分的迴歸測試造成的錯誤，因此可以用來提高程式設計師的工作效率。實際上，還有一種被稱為 Test-First Development [Beck2] 的方法，這種方法甚至提倡在開發實際的程式碼之前就先編寫單元測試。然而，在您測試程式碼之前，您需要將程式碼分割成一些可測試的片斷。一個"大泥球"是難以測試的，因為它不是隻實現一個簡單的易於識別的功能。如果您的每個程式碼片斷實現多個方面的功能，這樣的程式碼將難以保證其完全的正確性。

　　MVC 框架（以及 J2EE 中的 MVC 實現）的一個優點就是元素的元件化能夠（實際上，相當的簡單）對您的應用程式進行單元測試。因此，您可以方便地對實體 bean、會話 bean 以及 JSP 獨立編寫測試用例，而不必考慮其他的程式碼。現在有許多用於 J2EE 測試的框架和工具，這些框架及工具使得這一過程更加簡單。例如，JUnit（是一種由 junit.org 開發的開放原始碼工具）和 Cactus（由 Apache 開發的開放原始碼工具）對於測試 J2EE 元件都非常有用。[Hightower] 詳細探討了如何在 J2EE 中使用這些工具。

　　儘管所有這些詳述了怎樣徹底地測試您的應用程式，但是我們仍然看到一些人認為只要他們測試了 GUI（可能是基於 Web 的 GUI，或者是獨立的 Java 應用程式），則他們就全面地測試了整個應用程式。GUI 測試很難達到全面的測試，有以下幾種原因。首先，使用 GUI 測試很難徹底地測試到系統的每一條路徑，GUI 僅僅是影響系統的一種方式，可能存在後臺運算、指令碼和各種各樣的其他訪問點，這也需要進行測試。然而，它們通常並不具有 GUI。第二，GUI 級的測試是一種非常粗粒度的測試。這種測試只是在宏觀水平上測試系統的行為。這意味著一旦發現存在問題，則與此問題相關的整個子系統都要進行檢查，這使得找出 bug（缺陷）將是非常困難的事情。第三，GUI 測試通常只有在整個開發週期的後期才能很好地得到測試，這是因為只有這那個時候 GUI 才得到完整的定義。這意味著只有在後期才可能發現潛在的 bug。第四，一般的開發人員可能沒有自動的 GUI 測試工具。因此，當一個開發人員對程式碼進行更改時，沒有一種簡單的方法來重新測試受到影響的子系統。這實際上不利於進行良好的測試。如果開發人員具有自動的程式碼級單元測試工具，開發人員就能夠很容易地執行這些工具以確保所做的更改不會破壞已經存在的功能。最後，如果新增了自動構建功能，則在自動構建過程中新增一個自動的單元測試工具是非常容易的事情。當完成這些設定以後，整個系統就可以有規律地進行重建，並且迴歸測試幾乎不需要人的參與。

　　另外，我們必須強調，使用 EJB 和 Web 服務進行分散式的、基於元件的開發使得測試單個的元件變得非常必要。如果沒有"GUI"需要測試，您就必須進行低階（lower-level）測試。最好以這種方式開始測試，省得當您將分散式的元件或 Web 服務作為您的應用程式的一部分時，您不得不花費心思重新進行測試。

　　總之，透過使用自動的單元測試，能夠很快地發現系統的缺陷，並且也易於發現這些缺陷，使得測試工作變得更加系統化，因此整體的質量也得以提高。

　　3. 按照規範來進行開發，而不是按照應用伺服器來進行開發。

　　要將規範熟記於心，如果要背離規範，要經過慎密的考慮後才可以這樣做。這是因為當您背離規則的時候，您所做的事情往往並不是您應該做的事情。

　　當您要背離 J2EE 可以允許您做的事情的時候，這很容易讓使您遭受不幸。我們發現有一些開發人員鑽研一些 J2EE 允許之外的東西，他們認為這樣做可以"稍微"改善J2EE的效能，而他們最終只會發現這樣做會引起嚴重的效能問題，或者在以後的移植（從一個廠商到另一個廠商，或者是更常見的從一個版本到另一個版本）中會出現問題。實際上，這種移植問題是如此嚴重，以致 [Beaton] 將此原則稱為移植工作的基本最佳實踐。

　　現在有好幾個地方如果不直接使用 J2EE 提供的方法肯定會產生問題。一個常見的例子就是開發人員透過使用 JAAS 模組來替代 J2EE 安全性，而不是使用內建的遵循規範的應用程式伺服器機制來進行驗證和授權。要注意不要脫離 J2EE 規範提供的驗證機制，如果脫離了此規範，這將是系統存在安全漏洞以及廠商相容性問題的主要原因。類似地，要使用 servlet 和 EJB 規範提供的授權機制，並且如果您要偏離這些規範的話，要確保使用規範定義的 API（例如 getCallerPrincipal()）作為實現的基礎。透過這種方式，您將能夠利用廠商提供的強安全性基礎設施，其中，業務要求需要支援複雜的授權規則。

　　其他常見的問題包括使用不遵循 J2EE 規範的永續性機制（這使得事務管理變得困難）、在J2EE程式中使用不適當的J2SE 方法（例如執行緒或 singleton），以及使用您自己的方法解決程式到程式（program-to-program）的通訊，而不是使用 J2EE 內在支援的機制（例如 JCA、JMS 或 Web 服務）。當您將一個遵循 J2EE 的伺服器移植到其他的伺服器上，或者移植到相同伺服器的新版本上，上述的設計選擇將會造成無數的問題。唯一要背離規範的情況是，當一個問題在規範的範圍內無法解決的時候。例如，安排執行定時的業務邏輯在 EJB2.1 出現之前是一個問題，在類似這樣的情況下，我們建議當有廠商提供的解決方案時就使用廠商提供的解決方案（例如 WebSphere Application Server Enterprise 中的 Scheduler 工具），而在沒有廠商提供的解決方案時就使用第三方提供的工具。如果使用廠商提供的解決方案，應用程式的維護以及將其移植到新的規範版本將是廠商的問題，而不是您的問題。

　　最後，要注意不要太早地採用新技術。太過於熱衷採用還沒有整合到 J2EE 規範的其他部分或者還沒有整合到廠商的產品中的技術常會帶來災難性的後果。支援是關鍵的——如果您的廠商不直接支援一種特定的在 JSR 中提出的技術，但此技術還沒有被 J2EE 所接受，那麼您就不應該採用此技術。畢竟，我們中的大多數人從事解決業務問題，而不是推進技術的發展。