執行個體講解JSP Model2體繫結構（上）

最近已經有了很多相關的介紹，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體繫結構的概念，我們來看一個用它實現的例子：一個叫做“音樂無國界”的網上音樂市集。