12個最重要的J2EE最佳實踐(一）

最佳實踐

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 所接受，那麼您就不應該採用此技術。畢竟，我們中的大多數人從事解決業務問題，而不是推進技術的發展。