最佳實(shí)踐

　　1、始終使用 MVC 框架。
　　2、在每一層都應(yīng)用自動(dòng)單元測(cè)試和測(cè)試管理。
　　3、按照規(guī)范來進(jìn)行開發(fā)，而不是按照應(yīng)用服務(wù)器來進(jìn)行開發(fā)。
　　4、從一開始就計(jì)劃使用 J2EE 安全性。
　　5、創(chuàng)建您所知道的。
　　6、當(dāng)使用 EJB 組件時(shí)，始終使用會(huì)話 Facades。
　　7、使用無狀態(tài)會(huì)話 bean，而不是有狀態(tài)會(huì)話 bean.
　　8、使用容器管理的事務(wù)。
　　9、將 JSP 作為表示層的首選。
　　10、當(dāng)使用 HttpSession 時(shí)，盡量只將當(dāng)前事務(wù)所需要的狀態(tài)保存其中，其他內(nèi)容不要保存在 HttpSession 中。
　　11、在 WebSphere 中，啟動(dòng)動(dòng)態(tài)緩存，并使用 WebSphere servlet 緩存機(jī)制。
　　12、為了提高程序員的工作效率，將 CMP 實(shí)體 bean 作為 O/R 映射的首選解決方案。

　　1. 始終使用 MVC 框架。

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

　　MVC 框架對(duì)于成功使用 J2EE 是如此重要，以致沒有其他最佳實(shí)踐可以與其相提并論。模型-視圖-控制器（MVC）是設(shè)計(jì) J2EE 應(yīng)用程序的基礎(chǔ)。MVC 將您的程序代碼簡(jiǎn)單地劃分下面幾個(gè)部分：

　　·負(fù)責(zé)業(yè)務(wù)邏輯的代碼（即模型——通常使用 EJB 或者普通的 Java 對(duì)象來實(shí)現(xiàn)）。
　　·負(fù)責(zé)用戶界面顯示的代碼（即視圖——通常通過 JSP 及標(biāo)記庫來實(shí)現(xiàn)，有時(shí)也使用 XML 和 XSLT 來實(shí)現(xiàn)）。
　　·負(fù)責(zé)應(yīng)用程序流程的代碼（即控制器——通常使用 Java Servlet 或像 Struts 控制器這樣的類來實(shí)現(xiàn)）。

　　如果您不遵循基本的 MVC 框架，在開發(fā)過程中就會(huì)出現(xiàn)許多的問題。最常見的問題就是在視圖部分添加了太多的成分，例如，可能存在使用 JSP 標(biāo)記來執(zhí)行數(shù)據(jù)庫訪問，或者在 JSP 中進(jìn)行應(yīng)用程序的流程控制，這在小規(guī)模的應(yīng)用程序中是比較常見的，但是，隨著后期的開發(fā)，這樣做將會(huì)帶來問題，因?yàn)?JSP 逐步變得越來越難以維護(hù)和調(diào)試。

　　類似地，我們也經(jīng)常看到將視圖層構(gòu)建到業(yè)務(wù)邏輯的情況。例如，一個(gè)常見的問題就是將在構(gòu)建視圖時(shí)使用的 XML 解析技術(shù)直接應(yīng)用到業(yè)務(wù)層。業(yè)務(wù)層應(yīng)該對(duì)業(yè)務(wù)對(duì)象——而不是綁定到視圖的特定數(shù)據(jù)表示進(jìn)行操作。

　　然而，只是具有合適的組件并不一定意味著可以使您的應(yīng)用程序得到合適的分層。我們常常見到一些應(yīng)用程序包含 servlet、JSP 和 EJB 組件所有這三項(xiàng)，然而，其主要的業(yè)務(wù)邏輯卻是在 servlet 層實(shí)現(xiàn)的，或者應(yīng)用程序?qū)Ш绞窃?JSP 中處理的。您必須進(jìn)行嚴(yán)格的代碼檢查并重構(gòu)您的代碼，以確保應(yīng)用程序的業(yè)務(wù)邏輯只在模型層（Model layer）進(jìn)行處理，應(yīng)用程序?qū)Ш街煌ㄟ^控制器層（Controller layer）進(jìn)行處理，而您的視圖（Views）只是將傳遞過來的模型對(duì)象以 HTML 及 JavaScript 的形式表示出來。

　　2. 在應(yīng)用程序的每一層都使用自動(dòng)單元測(cè)試和測(cè)試管理。

　　不要只是測(cè)試您的圖形用戶界面（GUI)。分層的測(cè)試使測(cè)試及維護(hù)工作變得極其簡(jiǎn)單。

　　在過去的幾年中，在方法學(xué)領(lǐng)域有了相當(dāng)大的革新，例如新出現(xiàn)的被稱為 Agile（例如 SCRUM [Schwaber] 和極限編程 [Beck1]）的輕量級(jí)方法現(xiàn)在已經(jīng)得到了很普遍的應(yīng)用。幾乎所有的這些方法中的一個(gè)共同的特征是它們都提倡使用自動(dòng)的測(cè)試工具，這些工具可以幫助開發(fā)人員用更少的時(shí)間進(jìn)行回歸測(cè)試 (regression testing)，并可以幫助他們避免由于不充分的回歸測(cè)試造成的錯(cuò)誤，因此可以用來提高程序員的工作效率。實(shí)際上，還有一種被稱為 Test-First Development [Beck2] 的方法，這種方法甚至提倡在開發(fā)實(shí)際的代碼之前就先編寫單元測(cè)試。然而，在您測(cè)試代碼之前，您需要將代碼分割成一些可測(cè)試的片斷。一個(gè)"大泥球"是難以測(cè)試的，因?yàn)樗�不是只�?shí)現(xiàn)一個(gè)簡(jiǎn)單的易于識(shí)別的功能。如果您的每個(gè)代碼片斷實(shí)現(xiàn)多個(gè)方面的功能，這樣的代碼將難以保證其完全的正確性。

　　MVC 框架（以及 J2EE 中的 MVC 實(shí)現(xiàn)）的一個(gè)優(yōu)點(diǎn)就是元素的組件化能夠（實(shí)際上，相當(dāng)?shù)暮?jiǎn)單）對(duì)您的應(yīng)用程序進(jìn)行單元測(cè)試。因此，您可以方便地對(duì)實(shí)體 bean、會(huì)話 bean 以及 JSP 獨(dú)立編寫測(cè)試用例，而不必考慮其他的代碼�，F(xiàn)在有許多用于 J2EE 測(cè)試的框架和工具，這些框架及工具使得這一過程更加簡(jiǎn)單。例如，JUnit（是一種由 junit.org 開發(fā)的開放源代碼工具）和 Cactus（由 Apache 開發(fā)的開放源代碼工具）對(duì)于測(cè)試 J2EE 組件都非常有用。[Hightower] 詳細(xì)探討了如何在 J2EE 中使用這些工具。

　　盡管所有這些詳述了怎樣徹底地測(cè)試您的應(yīng)用程序，但是我們?nèi)匀豢吹揭恍┤苏J(rèn)為只要他們測(cè)試了 GUI（可能是基于 Web 的 GUI，或者是獨(dú)立的 Java 應(yīng)用程序），則他們就全面地測(cè)試了整個(gè)應(yīng)用程序。GUI 測(cè)試很難達(dá)到全面的測(cè)試，有以下幾種原因。首先，使用 GUI 測(cè)試很難徹底地測(cè)試到系統(tǒng)的每一條路徑，GUI 僅僅是影響系統(tǒng)的一種方式，可能存在后臺(tái)運(yùn)算、腳本和各種各樣的其他訪問點(diǎn)，這也需要進(jìn)行測(cè)試。然而，它們通常并不具有 GUI。第二，GUI 級(jí)的測(cè)試是一種非常粗粒度的測(cè)試。這種測(cè)試只是在宏觀水平上測(cè)試系統(tǒng)的行為。這意味著一旦發(fā)現(xiàn)存在問題，則與此問題相關(guān)的整個(gè)子系統(tǒng)都要進(jìn)行檢查，這使得找出 bug（缺陷）將是非常困難的事情。第三，GUI 測(cè)試通常只有在整個(gè)開發(fā)周期的后期才能很好地得到測(cè)試，這是因?yàn)橹挥羞@那個(gè)時(shí)候 GUI 才得到完整的定義。這意味著只有在后期才可能發(fā)現(xiàn)潛在的 bug。第四，一般的開發(fā)人員可能沒有自動(dòng)的 GUI 測(cè)試工具。因此，當(dāng)一個(gè)開發(fā)人員對(duì)代碼進(jìn)行更改時(shí)，沒有一種簡(jiǎn)單的方法來重新測(cè)試受到影響的子系統(tǒng)。這實(shí)際上不利于進(jìn)行良好的測(cè)試。如果開發(fā)人員具有自動(dòng)的代碼級(jí)單元測(cè)試工具，開發(fā)人員就能夠很容易地運(yùn)行這些工具以確保所做的更改不會(huì)破壞已經(jīng)存在的功能。最后，如果添加了自動(dòng)構(gòu)建功能，則在自動(dòng)構(gòu)建過程中添加一個(gè)自動(dòng)的單元測(cè)試工具是非常容易的事情。當(dāng)完成這些設(shè)置以后，整個(gè)系統(tǒng)就可以有規(guī)律地進(jìn)行重建，并且回歸測(cè)試幾乎不需要人的參與。

　　另外，我們必須強(qiáng)調(diào)，使用 EJB 和 Web 服務(wù)進(jìn)行分布式的、基于組件的開發(fā)使得測(cè)試單個(gè)的組件變得非常必要。如果沒有"GUI"需要測(cè)試，您就必須進(jìn)行低級(jí)（lower-level）測(cè)試。最好以這種方式開始測(cè)試，省得當(dāng)您將分布式的組件或 Web 服務(wù)作為您的應(yīng)用程序的一部分時(shí)，您不得不花費(fèi)心思重新進(jìn)行測(cè)試。

　　總之，通過使用自動(dòng)的單元測(cè)試，能夠很快地發(fā)現(xiàn)系統(tǒng)的缺陷，并且也易于發(fā)現(xiàn)這些缺陷，使得測(cè)試工作變得更加系統(tǒng)化，因此整體的質(zhì)量也得以提高。

　　3. 按照規(guī)范來進(jìn)行開發(fā)，而不是按照應(yīng)用服務(wù)器來進(jìn)行開發(fā)。

　　要將規(guī)范熟記于心，如果要背離規(guī)范，要經(jīng)過慎密的考慮后才可以這樣做。這是因?yàn)楫?dāng)您背離規(guī)則的時(shí)候，您所做的事情往往并不是您應(yīng)該做的事情。

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

　　現(xiàn)在有好幾個(gè)地方如果不直接使用 J2EE 提供的方法肯定會(huì)產(chǎn)生問題。一個(gè)常見的例子就是開發(fā)人員通過使用 JAAS 模塊來替代 J2EE 安全性，而不是使用內(nèi)置的遵循規(guī)范的應(yīng)用程序服務(wù)器機(jī)制來進(jìn)行驗(yàn)證和授權(quán)。要注意不要脫離 J2EE 規(guī)范提供的驗(yàn)證機(jī)制，如果脫離了此規(guī)范，這將是系統(tǒng)存在安全漏洞以及廠商兼容性問題的主要原因。類似地，要使用 servlet 和 EJB 規(guī)范提供的授權(quán)機(jī)制，并且如果您要偏離這些規(guī)范的話，要確保使用規(guī)范定義的 API（例如 getCallerPrincipal()）作為實(shí)現(xiàn)的基礎(chǔ)。通過這種方式，您將能夠利用廠商提供的強(qiáng)安全性基礎(chǔ)設(shè)施，其中，業(yè)務(wù)要求需要支持復(fù)雜的授權(quán)規(guī)則。

　　其他常見的問題包括使用不遵循 J2EE 規(guī)范的持久性機(jī)制（這使得事務(wù)管理變得困難）、在J2EE程序中使用不適當(dāng)?shù)腏2SE 方法（例如線程或 singleton），以及使用您自己的方法解決程序到程序（program-to-program）的通信，而不是使用 J2EE 內(nèi)在支持的機(jī)制（例如 JCA、JMS 或 Web 服務(wù)）。當(dāng)您將一個(gè)遵循 J2EE 的服務(wù)器移植到其他的服務(wù)器上，或者移植到相同服務(wù)器的新版本上，上述的設(shè)計(jì)選擇將會(huì)造成無數(shù)的問題。唯一要背離規(guī)范的情況是，當(dāng)一個(gè)問題在規(guī)范的范圍內(nèi)無法解決的時(shí)候。例如，安排執(zhí)行定時(shí)的業(yè)務(wù)邏輯在 EJB2.1 出現(xiàn)之前是一個(gè)問題，在類似這樣的情況下，我們建議當(dāng)有廠商提供的解決方案時(shí)就使用廠商提供的解決方案（例如 WebSphere Application Server Enterprise 中的 Scheduler 工具），而在沒有廠商提供的解決方案時(shí)就使用第三方提供的工具。如果使用廠商提供的解決方案，應(yīng)用程序的維護(hù)以及將其移植到新的規(guī)范版本將是廠商的問題，而不是您的問題。

　　最后，要注意不要太早地采用新技術(shù)。太過于熱衷采用還沒有集成到 J2EE 規(guī)范的其他部分或者還沒有集成到廠商的產(chǎn)品中的技術(shù)常會(huì)帶來災(zāi)難性的后果。支持是關(guān)鍵的——如果您的廠商不直接支持一種特定的在 JSR 中提出的技術(shù)，但此技術(shù)還沒有被 J2EE 所接受，那么您就不應(yīng)該采用此技術(shù)。畢竟，我們中的大多數(shù)人從事解決業(yè)務(wù)問題，而不是推進(jìn)技術(shù)的發(fā)展。