12個最重要的J2EE最佳實踐

2019-11-18 12:28:25

字體：大中小

來源：轉載

供稿：網友

　　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 所接受，那么您就不應該采用此技術。究竟，我們中的大多數人從事解決業務問題，而不是推進技術的發展。
　　
　　4. 從一開始就計劃使用 J2EE 安全性
　　
　　啟用 WebSphere 安全性。這使您的 EJB 和 URL 至少可以讓所有授權用戶訪問。不要問為什么——照著做就是了。
　　
　　在與我們合作的客戶中，一開始就打算啟用 WebSphere J2EE 安全性的顧客是非常少的，這一點一直讓我們感到吃驚。據我們估計大約只有 50% 的顧客一開始就打算使用此特性。例如，我們曾與一些大型的金融機構（銀行、代理等等）合作過，他們也沒有打算啟用安全性。幸運的是，這種問題在部署之前的檢查時就得以解決.
　　
　　不使用 J2EE 安全性是危險的事情。假設您的應用程序需要安全性（幾乎所有的應用程序都需要），您敢打賭您的開發人員能夠構建出自己的安全性系統，而這個系統比您從 J2EE 廠商那里買來的更好。這可不是個好的賭注，為分布式的應用程序提供安全性是異常困難的。例如，您需要使用網絡安全加密令牌控制對 EJB 的訪問。以我們的經驗看來，大多數自己構建的安全性系統是不安全的，并且有重大的缺陷，這使產品系統極其脆弱。
　　
　　一些不使用 J2EE 安全性的理由包括：擔心性能的下降，相信其他的安全性（例如 Netegrity SiteMinder

上一篇：教您最優的J2EE學習經驗和流程

下一篇：當前流行的J2EE WEB應用架構分析