劉艷鋒

長春職業(yè)技術(shù)學(xué)院，吉林 長春 130033

0 引言

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

1 MVC設(shè)計思想

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

1.1 模型

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

業(yè)務(wù)模型是MVC最主要的核心。也稱企業(yè)模型，它為企業(yè)提供一個框架結(jié)構(gòu)，以確保企業(yè)的應(yīng)用系統(tǒng)與企業(yè)經(jīng)常改進(jìn)的業(yè)務(wù)流程緊密匹配?？梢哉f，也就是說業(yè)務(wù)建模主要是從業(yè)務(wù)的角度而非技術(shù)角度對企業(yè)進(jìn)行建模。

1.2 視圖

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

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

1.3 控制

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

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

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

2 MVC設(shè)計模式的實現(xiàn)

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

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

3 MVC結(jié)構(gòu)

3.1 視圖

視圖是模型的展現(xiàn)，它提供用戶數(shù)據(jù)的交互。

在J2EE下，視圖的實現(xiàn)很簡單?？梢韵耖_發(fā)HTML界面一樣直接在集成開發(fā)環(huán)境下通過編寫JSP頁面來完成頁面開發(fā)本。一個頁面由多個子視圖組成；子視圖可以是最簡單JSP頁面。

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

3.2 控制器

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

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

現(xiàn)在我們總結(jié)MVC的處理過程，首先控制器接收用戶的請求，并決定應(yīng)該調(diào)用哪個模型來進(jìn)行處理，然后模型用業(yè)務(wù)邏輯來處理用戶的請求并返回數(shù)據(jù)，最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù)，并通過表示層呈現(xiàn)給用戶。

3.3 模型

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

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

[1]孫衛(wèi)琴.精通STRUTS基于MVC的JavaWeb設(shè)計與開發(fā)[M].電子工業(yè)出版社，2007，3.

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

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