| 雖然許多文章曾經讨論過J2EE最佳實踐。那麼，為什麼我還要再寫一篇文章呢？本文究竟與以前的文章有何不同或者說比其他文章好在哪呢？ 首先，本文的目标讀者是正在從事技術工作的架構師。為了避免浪費大家的才智，我會避免講述一些陳腐的最佳實踐，例如“日常建構（build daily）”、“測試一切（test everything）”和“經常內建（ integrate often）。 任何具有稱職架構師的項目都有分工明确的、定義良好的團隊結構。他們還為進行編碼檢查、建構代碼（每日或在需要時）、進行測試（單元、內建和系統的）、部署和配置/釋放管理而具備已記錄的過程。 其次，我将跳過通常吹捧的最佳實踐，例如“基于接口的設計”、“使用著名的設計模型”以及“使用面向服務的架構”等。相反，我将集中講述我曾學過并且使用了若幹年的6（不是很多）個方面的in-the-trench課程。最後，本文的目的是讓您思考一下自己的架構，提供工作代碼示例或者解決方案超出了本文的範圍。下面就讓我介紹一下這6課： 第1課：切勿繞過伺服器端驗證 作為一位軟體顧問，我曾有機會不但設計并實作了Web應用程式，而且還評估/稽核了許多Web應用程式。在複雜的、并且用JavaScript用戶端封裝的應用程式内，我經常遇到對使用者輸入資訊執行大量檢查的Web頁面。即使HTML元素具有資料有效性的屬性也如此，例如MAXLENGTH。隻有在成功驗證所有輸入資訊後，才能送出HTML表單。結果，一旦伺服器端收到通知表單（請求），便恰當地執行業務邏輯。 在此，您發現問題了麼？開發人員已經做了許多重要的假設。例如，他們假設所有的Web應用程式使用者都同樣誠實。開發人員還假設所有使用者将總是使用他們測試過的浏覽器通路Web應用程式。還有很多其他的假設。這些開發人員忘記了利用可以免費得到的工具，通過指令行很容易地模拟類似浏覽器的行為。事實上，通過在浏覽器視窗中鍵入适當的URL，您可以發送任何“posted”表單，盡管如此，通過禁用這些頁面的GET請求，您很容易地阻止這樣的“表單發送”。但是，您不能阻止人們模拟甚至建立他們自己的浏覽器來入侵您的系統。 根本的問題在于開發人員不能确定用戶端驗證與伺服器端驗證的主要差别。兩者的主要差别不在于驗證究竟發生在哪裡，例如在用戶端或者在伺服器端。主要的差别在于驗證背後的目的不同。 用戶端驗證僅僅是友善。執行它可為使用者提供快速回報??使應用程式似乎做出響應，給人一種運作桌面應用程式的錯覺。 另一方面，伺服器端驗證是建構安全Web應用程式必需的。不管在用戶端一側輸入的是什麼，它可以確定用戶端送往伺服器的所有資料都是有效的。 因而，隻有伺服器端驗證才可以提供真正應用程式級的安全。許多開發人員陷入了錯誤感覺的圈套：隻有在用戶端進行所有資料的驗證才能確定安全。下面是說明此觀點的一個常見的示例： 一個典型的登入頁面擁有一個用來輸入使用者名的文本框和一個輸入密碼的文本框。在伺服器端，某人在接收servlet中可能遇到一些代碼，這些代碼構成了下面形式的SQL查詢： "SELECT * FROM SecurityTable WHERE username = '" + form.getParameter("username") + "' AND password = '" + form.getParameter("password") + "';"，并執行這些代碼。如果查詢在結果集的某一行傳回，則使用者登入成功，否則使用者登入失敗。 第一個問題是構造SQL的方式，但現在讓我們暫時忽略它。如果使用者在使用者名中輸入“Alice'--”會怎樣呢？假設名為“Alice”的使用者已經在SecurityTable中，這時此使用者（更恰當的說法是黑客）成功地登入。我将把找出為什麼會出現這種情況的原因做為留給您的一道習題。 許多創造性的用戶端驗證可以阻止一般的使用者從浏覽器中這樣登入。但對于已經禁用了JavaScript的用戶端，或者那些能夠使用其他類似浏覽器程式直接發送指令（HTTP POST和GET指令）的進階使用者（或者說黑客）來說，我們又有什麼辦法呢？伺服器端驗證是防止這種漏洞類型所必須的。這時，SSL、防火牆等都派不上用場了。 第2課：安全并非是附加物 如第1課所述，我曾有幸研究過許多Web應用程式。我發現所有的JavaServer Page（JSP）都有一個共同的主題，那就是具有類似下面僞代碼的布局： <% User user = session.getAttribute("User"); if(user == null) { // redirect to // the logon page… } if(!user.role.equals("manager")) { // redirect to the // "unauthorized" page… } %> <!- HTML, JavaScript, and JSP code to display data and allow user interaction --> 如果項目使用諸如Struts這樣的MVC架構，所有的Action Bean都會具有類似的代碼。盡管最後這些代碼可能運作得很好，但如果您發現一個bug，或者您必須添加一個新的角色（例如，“guest”或者“admin”），這就會代表一場維護惡夢。 此外，所有的開發人員，不管您多年輕，都需要熟悉這種編碼模式。當然，您可以用一些JSP标簽來整理JSP代碼，可以建立一個清除派生Action Bean的基本Action Bean。盡管如此，由于與安全相關的代碼會分布到多個地方，是以維護時的惡夢仍舊存在。由于Web應用程式的安全是強迫建立在應用程式代碼的級别上（由多個開發人員），而不是建立在架構級别上，是以Web應用程式還是很可能存在弱點。 很可能，根本的問題是在項目接近完成時才處理安全性問題。最近作為一名架構師，我曾在一年多的時間裡親曆了某一要實作項目的6個版本，而直到第四版時我們才提到了安全性??即使該項目會将高度敏感的個人資料暴露于Web上，我們也沒有注意到安全性。為了更改釋出計劃，我們卷入了與項目資助人及其管理人員的争鬥中，以便在第一版中包含所有與安全相關的功能，并将一些“業務”功能放在後續的版本中。最終，我們赢得了勝利。而且由于應用程式的安全性相當高，能夠保護客戶的私有資料，這一點我們引以為榮，我們的客戶也非常高興。 遺憾的是，在大多數應用程式中，安全性看起來并未增加任何實際的商業價值，是以直到最後才解決。發生這種情況時，人們才匆忙開發與安全相關的代碼，而絲毫沒有考慮解決方案的長期可維護性或者健壯性。忽視該安全性的另一個征兆是缺乏全面的伺服器端驗證，如我在第1課中所述，這一點是安全Web應用程式的一個重要組成部分。 記住：J2EE Web應用程式的安全性并非僅僅是在Web.xml 和ejb-jar.xml檔案中使用合适的聲明，也不是使用J2EE技術，如Java 認證和授權服務（Java Authentication and Authorization Service，JAAS）。而是經過深思熟慮後的設計，且實作一個支援它的架構。 第3課：國際化（I18N）不再是紙上談兵 當今世界的事實是許多英語非母語的人們将通路您的公共Web應用程式。随着電子政務的實行，由于它允許人們（某個國家的居民）線上與政府機構互動，是以這一點特别真實。這樣的例子包括換發駕照或者車輛登記證。許多第一語言不是英語的人們很可能将通路這樣的應用程式。國際化（即：“i18n”，因為在“internationalization”這個單詞中，字母i和字母n之間一共有18個字母）使得您的應用程式能夠支援多種語言。 顯然，如果您的JSP 頁面中有寫死的文本，或者您的Java代碼傳回寫死的錯誤消息，那麼您要花費很多時間開發此Web應用程式的西班牙語版本。然而，在Web應用程式中，為了支援多種語言，文本不是惟一必須“具體化”的部分。因為許多圖像中嵌有文字，是以圖形和圖像也應該是可配置的。在極端的情況下，圖像（或者顔色）在不同的文化背景中可能有完全不同的意思。類似地，任何格式化數字和日期的Java代碼也必須本地化。但問題是：您的頁面布局可能也需要更改。 例如，如果您使用HTML表格來格式化和顯示菜單選項、應用程式題頭或注腳，則您可能必須為每一種支援的語言更改每一欄的最小寬度和表格其他可能的方面。為了适應不同的字型和顔色，您可能必須為每一種語言使用單獨的樣式表。 顯然，現在建立一個國際化的Web應用程式面臨的是架構挑戰而不是應用程式方面的挑戰。一個架構良好的Web應用程式意味着您的JSP頁面和所有與業務相關的（應用程式特有的）Java代碼都不知不覺地選擇了本地化。要記住的教訓是：不要因為Java、J2EE支援國際化而不考慮國際化。您必須從第一天起就記住設計具有國際化的解決方案。 第4課：在MVC表示中避免共同的錯誤 J2EE開發已經足夠成熟，在表示層，大多數項目使用MVC架構的某些形式，例如Struts。在這樣的項目中，我常見到的現象是對MVC模式的誤用。下面是幾個示例。 常見的誤用是在模型層（例如，在Struts的Action Bean中）實作了所有的業務邏輯。不要忘了，表示層的模型層仍然是表示層的一部分。使用該模型層的正确方法是調用适當的業務層服務（或對象）并将結果發送到視圖層（view layer）。用設計模式術語來說，MVC表示層的模型應該作為業務層的外觀（Fa?ade）來實作。更好的方法是，使用核心J2EE模式（Core J2EE Patterns）中論述到的Business Delegate模式。這段自書中摘錄的内容精彩地概述了将您的模型作為Business Delegate來實作的要點和優點： Business Delegate起到用戶端業務抽象化的作用。它抽象化，進而隐藏業務服務的實作。使用Business Delegate，可以降低表示層用戶端和系統的業務服務.之間的耦合程度。根據實作政策不同，Business Delegate可以在業務服務API的實作中，保護用戶端不受可能的變動性影響。這樣，在業務服務API或其底層實作變化時，可以潛在地減少必須修改表示層用戶端代碼的次數。 另一個常見的錯誤是在模型層中放置許多表示類型的邏輯。例如，如果JSP頁面需要以指定方式格式化的日期或者以指定方式排序的資料，某些人可能将該邏輯放置在模型層，對該邏輯來說，這是錯誤的地方。實際上，它應該在JSP頁面使用的一組helper類中。當業務層傳回資料時，Action Bean應該将資料轉發給視圖層。這樣，無需建立模型和視圖之間多餘的耦合，就能夠靈活支援多個視圖層（JSP、Velocity、XML等）。也使視圖能夠确定向使用者顯示資料的最佳方式。 最後，我見過的大多數MVC應用程式都有未充分應用的控制器。例如，絕大多數的Struts應用程式将建立一個基本的Action類，并完成所有與安全相關的功能。其他所有的Action Bean都是此基類的派生類。這種功能應該是控制器的一部分，因為如果沒有滿足安全條件，則首先調用不應該到達Action Bean（即：模型）。記住，一個設計良好的MVC架構的最強大功能之一是存在一個健壯的、可擴充的控制器。您應該利用該能力以加強自己的優勢。 第5課：不要被JOPO束縛住手腳 我曾目睹許多項目為了使用Enterprise JavaBean而使用Enterprise JavaBean。因為EJB似乎給項目帶來優越感和妄自尊大的表現，是以有時它是顯酷的要素（coolness factor）。而其他時候，它會使J2EE和EJB引起混淆。記住，J2EE和EJB不是同意詞。EJB隻是J2EE 的一部分，J2EE 是包含JSP、servlet、Java 消息服務（JMS）、Java資料庫連接配接（JDBC）、JAAS、 Java管理擴充（JMX）和EJB在内的一系列技術，同樣也是有關如何共同使用這些技術建立解決方案的一組指導原則和模式。 如果在不需要使用EJB的情況下使用EJB，它們可能會影響程式的性能。與老的Web伺服器相比，EJB一般對應用伺服器有更多的需求。EJB提供的所有增值服務一般需要消耗更大的記憶體和更多的CPU時間。許多應用程式不需要這些服務，是以應用伺服器要與應用程式争奪資源。 在某些情況下，不必要地使用EJB可能使應用程式崩潰。例如，最近我遇到了一個在開源應用伺服器上開發的應用程式。業務邏輯封裝在一系列有狀态會話bean（EJB）中。開發人員為了在應用伺服器中完全禁用這些bean的“鈍化”費了很大的勁。用戶端要求應用程式部署在某一商用應用伺服器上，而該伺服器是用戶端技術棧的一部分。該應用伺服器卻不允許關閉“鈍化”功能。事實上，用戶端不想改變與其合作的應用伺服器的設任何置。結果，開發商碰到了很大的麻煩。（似乎）有趣的事情是開發商自己都不能給出為什麼将代碼用EJB（而且還是有狀态會話bean）實作的好理由。不僅僅是開發商會遇到性能問題，他們的程式在客戶那裡也無法工作。 在Web應用程式中，無格式普通Java 對象（POJO）是EJB強有力的競争者。POJO是輕量級的，不像EJB那樣負擔額外的負擔。在我看來，對許多EJB的優點，例如對象入池，估計過高。POJO是您的朋友，不要被它束縛住手腳。 第6課：資料通路并不能托管O/R映射 我曾參與過的所有Web應用程式都向使用者提供從其他地方存取的資料，并且是以需要一個資料通路層。這并不是說所有的項目都需要辨別并建立這樣一個層，這僅僅說明這樣層的存在不是隐含的就是明确的。如果是隐含的資料層，資料層是業務對象（即：業務服務）層的一部分。這适用于小型應用程式，但通常與大一些項目所接受的架構指導原則相抵觸。 總之，資料通路層必須滿足或超出以下四個标準： 具有透明性 業務對象在不知道資料源實作的具體細節情況下，可以使用資料源。由于實作細節隐藏在資料通路層的内部，是以通路是透明的。 易于遷移 資料通路層使應用程式很容易遷移到其他資料庫實作。業務對象不了解底層的資料實作，是以遷移僅僅涉及到修改資料通路層。進一步地說，如果您正在部署某種工廠政策，您可以為每個底層的存儲實作提供具體的工廠實作。如果是那樣的話，遷移到不同的存儲實作意味着為應用程式提供一個新的工廠實作。 盡量減少業務對象中代碼複雜性 因為資料通路層管理着所有的資料通路複雜性，是以它可以簡化業務對象和使用資料通路層的其他資料用戶端的代碼。資料通路層，而不是業務對象，含有許多與實作相關的代碼（例如SQL語句）。這樣給開發人員帶來了更高的效率、更好的可維護性、提高了代碼的可讀性等一系列好處。 把所有的資料通路集中在單獨的層上 由于所有的資料通路操作現在都委托給資料通路層，是以您可以将這個單獨的資料通路層看做能夠将應用程式的其他部分與資料通路實作互相隔離的層。這種集中化可以使應用程式易于維護和管理。 注意：這些标準都不能明确地調出對O/R（對象到關系）映射層的需求。O/R映射層一般用O/R映射工具建立，它提供對象對關系資料結構的檢視和感覺（look-and-feel）。在我看來，在項目中使用O/R映射與使用EJB類似。在大多數情況下，并不要求它。對于包含中等規模的聯合以及多對多關系的關系型資料庫來說，O/R映射會變得相當複雜。由于增加O/R 映射解決方案本身的内在複雜性，例如延遲加載（lazy loading）、高速緩沖等，您将為您的項目帶來更大的複雜性（和風險）。 為了進一步支援我的觀點，我将指出按照Sun Microsystem所普及的實體Bean（O/R映射的一種實作）的許多失敗的嘗試，這是自1.0版以來一直折磨人的難題。在SUN的防衛措施中，一些早期的問題是有關EJB規範的開發商實作的。這依次證明了實體Bean規範自身的複雜性。結果，大多數J2EE架構師一般認為從實體Bean中脫離出來是一個好主意。 大多數應用程式在處理他們的資料時，隻能進行有限次數的查詢。在這樣的應用程式中，通路資料的一種有效方法是實作一個資料通路層，該層實作執行這些查詢的一系列服務（或對象、或API）。如上所述，在這種情況下，不需要O/R映射。當您要求查詢靈活性時，O/R映射正合适，但要記住：這種附加的靈活性并不是沒有代價的。 就像我承諾的那樣，在本文中，我盡量避免陳腐的最佳實踐。相反，關于J2EE項目中每一位架構師必須做出的最重要的決定，我集中講解了我的觀點。最後，您應該記住：J2EE并非某種具體的技術，也不是強行加入到解決方案中的一些首字母縮寫。相反，您應該在适當的時機，恰當的地方，使用合适的技術，并遵循J2EE的指導原則和J2EE中所包含的比技術本身重要得多的實踐。 | 
![1.6 Linux指令行使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)