【文章內(nèi)容簡介】 案而不必做重復勞動”[AIS+77，第 10 頁]。盡管 Alexander 所指的是城市和建筑模式，但他的思想也同樣適用于面向?qū)ο笤O計模式，只是在面向?qū)ο蟮慕鉀Q方案里，我們用對象和接口代替了墻壁和門窗。兩類模式的核心都在于提供了相關問題的解決方案。一般而言，一個模式有四個基本要素。即：模式名稱(pattern name)、問題(problem)、解決方案(solution)和效果(consequences)。模式有不同的領域，建筑領域有建筑模式，軟件設計領域也有設計模式。設計開發(fā)軟件為什么要用模式呢？因為模式是一種指導，在一個良好的指導下，有助于我們完成任務，有助于我們做出一個優(yōu)良的設計方案，達到事半功倍的效果，而且會得到解決問題的最佳辦法。 MVC 設計模式MVC 設計模式(ModelViewController，簡稱 MVC)是 80 年代在 Smalltalk80華中科技大學工程碩士學位論文10等主流面向?qū)ο缶幊陶Z言中出現(xiàn)的一種軟件設計模式，模型視圖控制結構是交互式應用程序廣泛使用的一種體系結構。它有效地在存儲和展示數(shù)據(jù)的對象中區(qū)分功能模塊以降低它們之間的連接度，這種體系結構將傳統(tǒng)的輸入、處理和輸入模型轉化為圖形顯示的用戶交互模型，或者換一種說法，是多層次的 Web 商業(yè)應用。 MVC 體系結構包括模型 Model、視圖 View 和控制器 Controller 三層，圖 21 是MVC 設計模式的結構圖 [19]，每個層面有其各自的功能作用，目前已被業(yè)界廣泛使用。在 MVC 設計模式中，實際上就是利用它的三層將應用系統(tǒng)分為三個組成部分。? 模型層模型層 Model：即事務邏輯模塊，是應用程序的主體部分，負責表達和訪問商業(yè)數(shù)據(jù)，執(zhí)行商業(yè)邏輯和操作。它采用面向?qū)ο蟮姆椒?，將問題領域中的對象抽象為應用程序?qū)ο?，在這些抽象的對象中封裝了對象的屬性和這些對象所隱含的邏輯。也就是說，這一層就是現(xiàn)實生活中功能的軟件模擬。在模型層變化時，它將通知視圖層，同時提供給視圖層訪問自身狀態(tài)的能力，控制層也可以訪問其功能函數(shù)以完成相關的任務。? 視圖層視圖層 View：即用戶視圖模塊，負責顯示模型層的內(nèi)容，主管應用程序與用戶之間的接口，負責用戶界面的生成。視圖可以向模型查詢業(yè)務的狀態(tài)，但不能去更改模型。在 MVC 模式里面，一個模型端可以有幾個視圖端，而實際上視圖端是使用 MVC 的原始動機。使用 MVC 模式可以允許多于一個的視圖端存在，并且可以在需要的時候動態(tài)地登記上所需的視圖。在 Web 應用程序中，一方面它為用戶提供了輸入手段，并觸發(fā)應用邏輯運行；另一方面，它又將應用邏輯運行的結果以某種形式顯示給用戶。華中科技大學工程碩士學位論文11模 型封裝應用程序狀態(tài)響應狀態(tài)查詢應用程序功能通知視圖改變視 圖解釋模型模型更新請求發(fā)送用戶請求給控制器允許控制器選擇視圖控制器定義應用程序行為用戶動作映射成模型選擇響應的視圖狀態(tài)查詢通知改變狀態(tài)改變視圖選擇用戶請求方法調(diào)用 事件圖 21 MVC 設計模式結構圖? 控制層控制層 Controller：即流程控制模塊，它是視圖 View 與模型 Model 間的接口，負責定義應用程序的行為。一方面它接收來自于視圖 View 的輸入，并將其解釋成系統(tǒng)能夠理解的對象，同時它也識別用戶動作，并將其解釋為對模型 Model 特定方法的調(diào)用；另一方面，它也處理來自于模型 Model 邏輯處理的結果，并調(diào)用適當?shù)囊晥D View 為用戶提供反饋。 MVC 設計模式與企業(yè)應用系統(tǒng)針對基于 MVC 設計模式的企業(yè)應用系統(tǒng)，在軟件的邏輯結構上可以劃分成三層：表現(xiàn)層、企業(yè)邏輯層和數(shù)據(jù)層。表現(xiàn)層包括所有的用戶接口，它是 MVC 設計模式中視圖和控制器的結合；企業(yè)邏輯層是 MVC 設計模式中 Model；數(shù)據(jù)層為應用程序提供所要求的任何數(shù)據(jù)的持久性服務，通常采用數(shù)據(jù)庫管理系統(tǒng)來實現(xiàn)。在基于 MVC 設計模式進行企業(yè)應用系統(tǒng)開發(fā)時，只要各個模塊之間的接口一旦制定，開發(fā)人員就可以根據(jù)模塊的主要功能選用適當?shù)募夹g對該模塊進行有針對性的開發(fā)，且無須熟悉實現(xiàn)其他模塊的具體技術細節(jié)，最后根據(jù)所制定的接口進行系統(tǒng)集成即可。盡管 MVC 設計模式很早就提出，并且使用 MVC 設計模式進行軟件系統(tǒng)開發(fā)具有許多優(yōu)點，但在 Web 項目的開發(fā)中引入 MVC 卻是步履維艱，主要原因有：一方面，在早期 Web 項目的開發(fā)中，程序語言和 HTML 的分離一直難以實現(xiàn)，盡管相繼出現(xiàn)了 CGI 技術和腳本語言，對 Web 項目的開發(fā)應用有一定的推動作用，華中科技大學工程碩士學位論文12但這兩種方式仍然無法實現(xiàn)程序語言和 HTML 分離。另一方面，腳本語言的功能相對較弱，缺乏支持 MVC 設計模式的一些必要的技術基礎。直到基于 J2EE 的JSP Model 2 體系結構的問世才得以改觀，它用 JSP 技術實現(xiàn)視圖的功能，用Servlet 技術實現(xiàn)控制器的功能，用 JavaBean 技術實現(xiàn)模型的功能。從而，真正地推動了 MVC 設計模式在 Web 項目開發(fā)中的應用 [20]。 JSP 體系結構 JSP 體系結構就是利用 JSP 技術開發(fā) Web 應用系統(tǒng)的軟件體系結構，在早期的 JSP 規(guī)范中給出了使用 JSP 技術構建 Web 應用系統(tǒng)的兩種方法。這兩種方法就是 JSP Model 1 和 JSP Model 2 體系結構。盡管在 JSP 規(guī)范中不再使用這些術語，但 Web 層開發(fā)團體中卻仍然在使用。下面，對兩種 JSP 體系結構作簡單介紹。圖 22 JSP Model 1 體系結構（1） Model 1 體系結構Model 1 體系結構見圖 22 所示，在這種系統(tǒng)結構中， JSP 頁面負責處理請求過程，并將輸出結果顯示給客戶端?？梢钥吹?，在此過程中沒有涉及到額外的Servlet，客戶端請求直接發(fā)送給 JSP 頁面，JSP 頁面與 JavaBean 或其他服務通信，但是最終 JSP 頁面為客戶端選擇下一頁。對下一個頁面的選擇，可以根據(jù)所選擇的 JSP 頁面或客戶端請求中的參數(shù)決定下一個視圖。在 JSP 頁面中結合業(yè)務邏輯、服務器端處理程序和 HTML，在 JSP 頁面中同時實現(xiàn)顯示、業(yè)務邏輯和流程控制，從而快速的完成 Web 應用開發(fā)。（2） Model 2 體系結構Model 2 體系結構見圖 23 所示 [21]，與 Model 1 體系結構相比，在 Model 2 體系結構中，Servlet 首先攔截客戶端請求，此 Servlet 也被稱為控制器 Servlet。此Servlet 處理請求的初始處理過程，并決定要顯示的下一個 JSP 頁面。Browser JSPJavaBeanRequestResponseApplication Server Enterprise Servers/Data Sources瀏覽器Response1234華中科技大學工程碩士學位論文13在 Model 2 體系結構中，客戶端不直接向 JSP 頁面發(fā)送請求。當 Servlet 攔截客戶端請求后，允許 Servlet 執(zhí)行前端處理過程，包括身份驗證和授權，集中登錄，并幫助進行國際化設置。一旦完成了請求處理過程，Servlet 就將請求發(fā)送到正確的 JSP 頁面。在不同的應用程序中，決定下一個頁面的方式可以不相同。例如，在簡單的 Web 應用程序中，要顯示的下一個 JSP 頁面可以根據(jù)請求參數(shù)和當前的應用程序狀態(tài)硬編碼進 Servlet。在復雜的 Web 應用程序中，可以使用工作流/規(guī)則引擎。圖 23 JSP Model 2 體系結構因此，這兩種方法的主要區(qū)別在于 Model 2 體系結構引入了控制器 Servlet，它提供了單一的入口點，比 Model 1 方法具有更多的可重用和可擴展性。Model 2體系結構中可以清晰地區(qū)分業(yè)務邏輯、顯示輸出和請求處理過程。這種分解模型就是 MVC 設計模式的具體體現(xiàn)。雖然 Model 2 體系結構看上去可能非常復雜，但是它確實大大簡化了應用程序，使用 Model 2 方法構建的 Web 應用程序通常比使用 Model 1 體系結構構建的應用程序易于維護，也更具有擴展性。人力資源規(guī)劃系統(tǒng)是一個業(yè)務邏輯復雜、需求靈活多變，某些業(yè)務子系統(tǒng)在數(shù)據(jù)結構保持穩(wěn)定的情況下，操作模式可能會經(jīng)常發(fā)生變化，因此如何保證該系統(tǒng)易于維護和擴展成為分析、設計、實現(xiàn)的首要問題?；?MVC 模式的 JSP Model 2 體系結構應用框架就是一個能將視圖、控制和業(yè)務處理相分離的參考解決方案。 本章小結通過對軟件體系結構、MVC 設計模式、JSP 體系結構技術進行介紹，基于3BROWSER （Controller）Servelet(Model)JavaBeanRequestApplication ServerEnterprise Servers/Data SourcesBrowser124（View）JSPInstantiate5 Response華中科技大學工程碩士學位論文14MVC 模式的 JSP Model 2 體系結構應用框架是一個能將視圖、控制和業(yè)務處理相分離的參考解決方案。它用 JSP 技術實現(xiàn)視圖的功能，用 Servlet 技術實現(xiàn)控制器的功能，用 JavaBean 技術實現(xiàn)模型的功能，從而真正地推動了 MVC 設計模式在Web 項目開發(fā)中的應用。 華中科技大學工程碩士學位論文153 改進型 MVC 應用框架的設計與實現(xiàn)Struts 的確是一個優(yōu)秀的 Web 應用框架，但是仍有一些不足之處。因此，提出設計改進型 MVC 應用框架的理由及使用的主要技術，規(guī)劃設計了 IMVC 頂級包的構成方案，接著對 IMVC 的模型進行重點研究，提出一種優(yōu)化分層模型的設計方案，并對該方案的具體實現(xiàn)做深入的研究和設計。 MVC 與 IMVC隨著 Web 開發(fā)技術的日趨成熟，在 Web 開發(fā)領域出現(xiàn)了一些現(xiàn)成的優(yōu)秀的框架，開發(fā)者可以直接使用它們，Struts 就是一種不錯的選擇，它是基于 MVC 的Web 應用框架。下面對 Struts 作簡單分析,并由此提出了構建 IMVC 應用框架的理由。 基于 Struts 實現(xiàn)的 MVC 框架Struts 實質(zhì)上就是在 JSP Model 2 的基礎上實現(xiàn)的一個 MVC 框架。在 Struts 框架中，模型實現(xiàn)業(yè)務邏輯的 JavaBean 或 EJB 組件構成，控制器由 ActionServlet 和Action 來實現(xiàn)，視圖由一組 JSP 文件構成?；?Struts 實現(xiàn)的 MVC 框架 [22] 如圖31 所示。圖 31 基于 Struts 實現(xiàn)的 MVC 框架(1)．視圖視圖就是一組 JSP 文件。這些 JSP 文件中沒有業(yè)務邏輯，也沒有模型信息，瀏覽器Servlet/JSP 容器Web服務器(控制器)ActionServlet(視圖)JSP(模型)JavaBeanEJBActionActionAction華中科技大學工程碩士學位論文16只有標簽，這些標簽可以是標準的 JSP 標簽或客戶化標簽，如 Struts 標簽庫中的標簽。此外，通常把 Struts 框架中的 ActionForm Bean 也劃分到視圖模塊中。ActionForm Bean 也是一種 JavaBean，除了具有一些 JavaBean 的常規(guī)方法，還包含一些特殊的方法，用于驗證 HTML 表單數(shù)據(jù)，并將其屬性重新設置為默認值。Struts 框架利用 ActionForm Bean 來進行視圖和控制器表單數(shù)據(jù)的傳遞。(2)．模型模型表示應用程序的狀態(tài)和業(yè)務邏輯。對于大型應用，業(yè)務邏輯通常由JavaBean 或 EJB 組件來實現(xiàn)。(3)．控制器控制器由 ActionServlet 類和 Action 類來實現(xiàn) [23]。ActionServlet 類是 Struts 框架中的核心組件，它在 MVC 模型中扮演中央控制器的角色。ActionServlet 主要負責接收 HTTP 請求信息，根據(jù)配置文 的配置信息，把請求轉發(fā)給適當?shù)?Action 對象。如果 Action 對象不在，則 ActionServlet 創(chuàng)建 Action 對象。Action 負責調(diào)用模型的方法，更新模型的狀態(tài)，并幫助控制應用程序的流程。 IMVC 應用框架的設計思想Struts 的確是一個優(yōu)秀的 Web 應用框架，但是仍有一些不足之處，Struts 是一個研究性項目 [24]，仍在不斷改進和提升當中，對于開發(fā)很大的項目，當 struts 越來越龐大時，維護也就變得越來越復雜，甚至需要專人負責；Struts框架主要是針對表示層設計的，沒有在建立模型組件方面做深入研究，對于后端邏輯層的支持不是很強，用戶在模型實現(xiàn)上需要做大量的工作，不利于快速開發(fā)和軟件復用。由于傳統(tǒng)的 MVC 設計模型主要是面向一般的應用程序，而 Web 應用程序有著與工程類應用程序不同的特點：即客戶端和服務器端之間以 HTTP 協(xié)議進行通信，而 HTTP 協(xié)議是一種無狀態(tài)連接協(xié)議，這種無狀態(tài)連接很難將更改通知視圖。所以要對傳統(tǒng)的 MVC 設計模型進行改造。在我們的實際開發(fā)中，需要底層能夠提供良好的數(shù)據(jù)庫訪問管理手段，使開發(fā)人員不需要去處理諸如數(shù)據(jù)庫的連接配置、連接池的管理、意外的捕獲等，只要了解底層的接口，便能在程序中進行數(shù)據(jù)庫的相關處理，從而加快