J2EE架構的6個最佳實務

雖然許多文章曾經討論過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請求，您很容易地阻止這樣的“表單發送”。但是，您不能阻止人們類比甚至建立他們自己的瀏覽器來入侵您的系統。
　根本的問題在於開發人員不能確定用戶端驗證與伺服器端驗證的主要差別。兩者的主要差別不在於驗證究竟發生在哪裡，例如在用戶端或者在伺服器端。主要的差別在於驗證背後的目的不同。
　　　用戶端驗證僅僅是方便。執行它可為使用者提供快速反饋??使應用程式似乎做出響應，給人一種運行傳統型應用程式的錯覺。