最佳實踐
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 中使用這些工具。
