從Servlet到JSP，從Model1到Model2

Servlet的出現

Servlet技術和JSP技術是利用Java語言開發Web應用程式的兩個主要技術，1996年Sun公司首次推出Servlet技術來解決Web程式當中的效能問題。Servlet在首次被使用者請求的時候載入到記憶體當中，之後將一直駐留在記憶體裡，對同一個servlet的後續請求將不用再對這個servlet的類進行執行個體化，這種機制大大提高了Web應用程式的相應速度。

可是Servlet並不是那麼完美，當人們在編寫Servlet的時候發現所有HTML輸出代碼都封裝在String對象裡，然後再用out對象的print方法向使用者展示出來，這不免增加了編碼的難度，而且維護起來也十分麻煩，即使稍微一點點的改動也需要重新編譯Servlet才行。

JSP以及相關技術的出現

Sun公司意識到了這個問題，並提出了JSP技術。JSP允許Java代碼和HTML標籤混雜在一起以簡化頁面的開發，修改頁面無需重新編譯，當第一次被請求的時候如果原先的JSP有變化則重新自動編譯，如果沒有變化則直接載入已經存在的執行個體。

但是問題又接踵而至：

l  Java代碼和HTML代碼（邏輯和顯示）混雜在一起使得程式變得難以閱讀和維護

l  把代碼放在JSP當中很難重用，這與物件導向的思想是相悖的

l  JSP當中編寫代碼IDE對此支援的並不是那麼十分的出色

l  測試變得困難

邏輯和顯示混雜是不被人們所提倡的，早在JSP1.0規範中就鼓勵程式員使用JavaBean將商務邏輯代碼封裝，從而把顯示和業務分開。但是事情並不像想象的那麼美好，在JSP當中對JavaBean中的方法命名必須遵守其命名規範，所以偶爾會出現某個方法的名字非常冗長難記。為了實現代碼和HTML更容易的分離JSP1.1定義了幾個自訂標籤庫，他們比JavaBean更加靈活易用。

但是舊的問題解決了，新的問題出現：自訂標籤庫很難編寫，並且JSP1.1中的自訂標籤有著非常複雜的生命週期。

後來人們開始給有關的標籤添加一些特定的常用功能。這些標籤庫編譯為幾個庫檔案，統稱為JSTL（JavaServer Pages Standard Tag Libraries，JSP標準標籤庫）。

儘管有了JavaBean，JSTL等技術可以把商務邏輯和顯示代碼分開，但是還是有很多開發人員貪圖方便或者說目光短淺，仍將邏輯與顯示的代碼混雜在一起。

Model1設計模型

至此出現了Java語言開發Web應用的第一種設計模型我們稱之為Model1，簡而言之就是只用JSP不使用Servlet，將頁面代碼和邏輯代碼混雜在一起。從一個JSP頁面到另外一個JSP頁面是通過頁面裡的連結完成的。

這種模式的問題就向上面所說的，對於小項目而言開發可能方便了一些。但是對於大型項目，開發是苦不堪言的，因為這種架構不利於網頁設計師和Web開發人員之間的勞動分工：開發人員既要參與頁面的開發，又要參與商務邏輯的編碼。維護起來就更加痛苦了，邏輯與顯示代碼混雜、頁面之間的聯絡是通過連結（這意味著一旦頁面名字改變那麼任何使用這個頁面的其他頁面都要更改，嚴重的違背了物件導向的思想）這對開發人員來說儼然就是一場噩夢。

Model2設計模型

於是第二種設計模型出現了，我們稱之為Model2，這個模型是MVC（Model-View-Controller，模型-視圖-控制器）設計模式的另一個名字。按照Model2模型開發的應用程式由三種主要部分組成：模型、視圖、和控制器。

在Model2模型裡，所有的頁面都有一個共同的進入點，通常是用一個Servlet或者過濾器（其中Struts1用的是Servlet，而Struts2用的是過濾器）來充當控制器。控制器部分負責接收來自使用者輸入並控制模型和視圖部分做出相應的變化；視圖部分負責實現應用程式的資訊顯示功能；模型部分封裝著應用程式的資料和商務邏輯。而在這樣的應用程式裡，每一個HTTP請求都必須定向到控制器，而潛在各個請求中的URI裡的資訊將告訴這個控制需要調用哪些動作。控制器檢查每個URI以決定應該調用哪些動作。它還將動作對象儲存在一個可以從視圖訪問的地方，這樣伺服器端的值就可以顯示在瀏覽器上了。最後控制器使用RequestDispatcher對象把請求傳遞給視圖（即相應的JSP頁面），再由JSP頁面裡的定義標籤把動作對象的內容顯示出來。

整個的發展流程

原來：技術的發展是由問題堆砌起來的。

後面將分別示範用Servlet和過濾器作為控制器實現Model2設計模型，其實可以看作是Struts1和Struts2的demo。