MVC設計模式的分析與應用

劉艷鋒

長春職業技術學院，吉林 長春 130033

0 引言

MVC架構是“Model-View-Controller” 的縮寫，即“模型-視圖-控制器”。MVC程序是由這3個部分組成。MVC架構是一個復雜的架構，其設計和實現也是相對復雜的。但是，我們已經設計了功能和安全性很好的設計模式，并且可以把多種設計模式結合在一起，使MVC架構的實現轉換為相對較為容易的代碼實現。

1 MVC設計思想

MVC的思想是把一個應用程序的數據輸入、數據處理、結果輸出流程按照Model、View、Controller的方式進行有組織的分離，看似分離卻又是統一。這樣一個應用程序設計被分成3個部分：模型層、視圖層、控制層。

1.1 模型

模型是應用程序的主體部分。模型表示業務數據和業務邏輯，一個模型能為多個視圖提供數據。由于同一個模型可以被多個視圖重用，所以提高了應用的可重用性。

業務模型是MVC最主要的核心。也稱企業模型，它為企業提供一個框架結構，以確保企業的應用系統與企業經常改進的業務流程緊密匹配。可以說，也就是說業務建模主要是從業務的角度而非技術角度對企業進行建模。

1.2 視圖

視圖是用戶交互界面，對于Web應用程序來說，可以是HTML，JSP等界面。

隨著應用程序的復雜度的提高和規模的擴大，界面的處理也變得非常復雜。應用程序可能有很多不同風格和類型的視圖，MVC設計模式對于視圖的操作只是數據的采集和處理，以及用戶的請求，而不能進行業務流程的處理，也就是帶有功能操作的部分交予模型處理。例如一個購物車的視圖只接受來自模型的數據并顯示給用戶，以及將用戶界面的輸入數據和請求傳遞給控制和模型。

1.3 控制

控制器接受用戶的輸入并調用模型和視圖去完成用戶的需求。當Web用戶單擊Web頁面中的提交按鈕來發送HTML表單時，控制器接收請求并調用相應的模型組件去處理請求，然后調用相應的視圖來顯示模型返回的數據。

控制（Controller）可以理解為從用戶接收請求，將模型與視圖匹配在一起，共同完成用戶的請求。或者簡單的理解，就是程序的處理流程由它來控制。

模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據，所有其它依賴于這些數據的視圖都應反映到這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，導致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關系和各自的主要功能。

2 MVC設計模式的實現

Java 平臺企業版和其他的各種框架不一樣，J2EE為模型對象定義了一個規范。

在J2EE應用程序中，視圖可能由Java Server Page承擔。生成視圖的代碼則可能是一個servlet的一部分，特別是在客戶端服務端交互的時候。J2EE應用中，控制器可能是一個servlet，現在一般用Struts實現。模型則是由一個實體Bean來實現。

3 MVC結構

3.1 視圖

視圖是模型的展現，它提供用戶數據的交互。

在J2EE下，視圖的實現很簡單。可以像開發HTML界面一樣直接在集成開發環境下通過編寫JSP頁面來完成頁面開發本。一個頁面由多個子視圖組成；子視圖可以是最簡單JSP頁面。

視圖部分大致處理流程如下：首先，定義了頁面的布局；頁面配置文件定義視圖標簽的具體內容；然后，由編寫代碼.這一部分主要定義了WEB頁面基類PageBase；頁面布局策略類PageLayout，完成頁面布局，用于加載用戶部件到頁面；用戶部件基類UserControlBase即用戶部件框架，用于動態加載檢驗部件，以及實現用戶部件的個性化。為了實現WEB應用的靈活性，視圖部分也用到了許多配置文件例如：置文件有模板配置、頁面配置、路徑配置、驗證配置等。

3.2 控制器

控制器接受用戶的輸入并調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調用哪個模型構件去處理請求，然后用確定用哪個視圖來顯示模型處理返回的數據。

在struts中，基本的控制器組件是ActionServlet類中的實例servelt，實際使用的servlet在配置文件中由一組映射（由ActionMapping類進行描述）進行定義。對于業務邏輯的操作則主要由Action、ActionMapping、ActionForward這幾個組件協調完成的，其中Action扮演了真正的業務邏輯的實現者，ActionMapping與ActionForward則指定了不同業務邏輯或流程的運行方向。strutsconfig.xml 文件配置控制器。現在我們總結M VC的處理過程，首先控制器接收用戶的請求，并決定應該調用哪個模型來進行處理，然后模型用業務邏輯來處理用戶的請求并返回數據，最后控制器用相應的視圖格式化模型返回的數據，并通過表示層呈現給用戶。

現在我們總結MVC的處理過程，首先控制器接收用戶的請求，并決定應該調用哪個模型來進行處理，然后模型用業務邏輯來處理用戶的請求并返回數據，最后控制器用相應的視圖格式化模型返回的數據，并通過表示層呈現給用戶。

3.3 模型

模型表示企業數據和業務規則。在MVC的3個部件中，模型擁有最多的處理任務。例如：它可能用象EJBs和ColdFusion Components這樣的構件對象來處理數據庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由于應用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。

業務邏輯層在體系架構中的位置很關鍵，它處于數據訪問層與表示層中間，起到了數據交換中承上啟下的作用。由于層是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那么這種向下的依賴也應該是一種弱依賴關系。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正因為如此，業務邏輯層的設計對于一個支持可擴展的架構尤為關鍵，因為它扮演了兩個不同的角色。對于數據訪問層而言，它是調用者；對于表示層而言，它卻是被調用者。依賴與被依賴的關系都糾結在業務邏輯層上，如何實現依賴關系的解耦，則是除了實現業務邏輯之外留給設計師的任務。

[1]孫衛琴.精通STRUTS基于MVC的JavaWeb設計與開發[M].電子工業出版社，2007，3.

[2]占東明.基于J2EE的MVC設計模式的分析與思考[J].科技廣場，2008，3.

[3]林善茂.MVC設計模式.http://www.csai.cn，2007，12.