最近已經有了很多相關的介紹，JSP正在成為一種卓越的Java技術，可用於創建動態Web應用程序。Java程序員之所以喜愛JSP有數不清的理由。有些人喜歡它為交互式頁面帶來的“一次編寫，處處使用”的方式；還有些人欣賞它是因為它容易學習，並且使他們可以把Java作為一種服務器端腳本語言來使用。但更多的還都是因為一個共同原因――使用JSP的最大好處是它能幫助你有效地把表達與內容分離開。在本文中，我對下面的問題作了深入探討，那就是，如何使用JSP Model 2體系結構獲得最佳的表達－內容分離效果。這個模型也可以被看作是通用MVC設計模式在服務器端的一個實現。請注意，在閱讀本文之前，你需要熟悉基本的JSP和servlet編程，因為文中將不會涉及到任何語法規則問題。
Servlets有什麼問題？
盡管JSP在動態Web內容服務和分離內容與表達上可以做得非常好，但仍然會有人置疑，為什麼要把servlets丟在一邊呢？其實servlets的作用不容置疑。它們在服務器端處理上做得很優秀，而且，由於它們已有了堅實的基礎，所以仍將被保留。實際上，從結構上講，你可以把JSP看作是servlets的一種高級抽象，就像Servlet2.1 API的一種擴充一樣來實現。然而，你也不應當濫用servlets，它們並非對每個人都適用。舉個例子，如果網頁設計者能夠很容易地用傳統HTML或XML工具寫出JSP頁的話，servlets就更適合那些後台程序的開發者，因為servlets通常是用集成開發環境（IDE）編寫的――一般來說這種方式需要更高級的編程技能。在運用servlets時，即使是開發者也必須小心謹慎以確保表達和內容不存在緊密的聯系。要做到這一點，你通常可以使用第三方HTML包（比如htmlKona）來混合代碼。但即便是這種方法，盡管它通過簡單的屏幕變換帶來了一些靈活性，卻無法幫你避免表達格式本身的改動。例如，如果你的表達格式從HTML變為DHTML，你就必須確保那些語言包適應新的格式。假設一種最壞的情況，如果一個包不可用，你也許將不得不忙於在動態內容中艱難地編寫表達，這會把你累死。那麼，如何解決這個問題呢？接下來你將看到，使用JSP與servlets技術相結合是構建應用系統地一種好方法。
不同的體系
早期的JSP規范提出了兩種用JSP技術建立應用程序的方式。這兩種方式在術語中分別稱作JSP Model 1 和JSP Model 2，它們的本質區別在於處理批量請求的位置不同。在Model 1體系中，如圖1所示，jsp頁面獨自響應請求並將處理結果返回客戶。這裡仍然存在表達與內容的分離，因為所以的數據存取都是由bean來完成的。盡管Model 1體系十分適合簡單應用的需要，它卻不能滿足復雜的大型應用程序的實現。不加選擇地隨意運用Model 1，會導致JSP頁內被嵌入大量的腳本片段或Java代碼，特別是當需要處理的請求量很大時，情況更為嚴重。盡管這對於Java程序員來說可能不是什麼大問題，但如果JSP頁面是由網頁設計人員開發並維護的――通常這是開發大型項目的規范――這就確實是個問題了。從根本上講，將導致角色定義不清和職責分配不明，給項目管理帶來不必要的麻煩。
圖1：JSP Model 1 體系結構
圖中文字：BROWSER：浏覽器；Request：請求；Response：響應；Application Server：應用服務器；Enterprise Servers/Data Sources：企業服務器/數據源。
Model 2體系結構，如圖2所示，是一種把JSP與servlets聯合使用來實現動態內容服務的方法。它吸取了兩種技術各自的突出優點，用JSP生成表達層的內容，讓servlets完成深層次的處理任務。在這裡，servlets充當控制者的角色，負責管理對請求的處理，創建JSP頁需要使用的bean和對象，同時根據用戶的動作決定把那個JSP頁傳給請求者。特別要注意，在JSP頁內沒有處理邏輯；它僅負責檢索原先由servlets創建的對象或beans，從servlet中提取動態內容插入靜態模板。在我看來，這是一種有代表性的方法，它清晰地分離了表達和內容，明確了角色的定義以及開發者與網頁設計者的分工。事實上，項目越復雜，使用Model 2體系結構的好處就越大。
圖2：JSP Model 2體系結構
圖中文字：instantlate：瞬間延時；Controller、View、Model分別為MVC設計模式中的控制者、試圖、模型；其他同圖1。
為了進一步闡明Model 2體系結構的概念，我們來看一個用它實現的例子：一個叫做“音樂無國界”的網上音樂商店。
