三層架構和MVC模式

1、 WEB三層架構與MVC爛而我發(fā)此文的目的有二：一者，讓初學者能夠聽到一家之言，是為解惑；二者，更希望拋磚 引玉，得到專家的批判。許多學生經(jīng)常問我，MVC到底和WEB三層架構有啥關系？開始時，我也只能給他們一些 模糊的回答。時間長了，自己的良心開始受到譴貴。對于一個程序員來說，這個問題顯得挺 學究。我在跟自己的許多程序員朋友以及同行(Java講師)都對MVC和WEB三層架構的關 系做了探討。現(xiàn)在可以說對WEB三層架構和MVC之間的關系理出了頭緒。此町謂教學相 長。先說說Web三層架構這個占老話題。地球人都知道web三層架構是指： 用戶接口層(Ul Layer) 業(yè)務邏輯層(Bussiness

2、Layer) 持久化層關于業(yè)務邏輯和用戶接口在早期的web開發(fā)中，因為業(yè)務比較簡單，并沒有這三層的劃分。用戶數(shù)據(jù)的呈現(xiàn)及輸入 的接收、封裝、驗證、處理、以及對數(shù)據(jù)庫的操作，都放在jsp頁面中。這時的開發(fā)，好比 盤占尚未開天辟地，整個web開發(fā)就是一片“混沌”。隨著業(yè)務越來越復雜，人們開始考慮 更好的利用OOP這把利刃來解決問題。于是有人發(fā)現(xiàn)把業(yè)務邏輯抽取出來并形成與顯示和 持久化無關的一層，能夠讓業(yè)務邏輯清晰，產品更便于維護。這就是SUN當初倡導的JSP Model 1開發(fā)方式。關于持久化JSPM1開發(fā)方式中，并沒有對數(shù)據(jù)如何持久化給出建議。在許多公司中，它們的產品是以 數(shù)抵庫為中心進行架構和

3、設計的。在他們的產晶里，雖然也有DAO層，但是職貴不淸。為 什么這么說呢，因為我發(fā)現(xiàn)在許多人眼里，DAO層的指貴很簡單一增刪改查。但我認為， 這樣理解實際上是本末倒置了。對于簡單數(shù)據(jù)的管理來說，這樣理解無可厚非。但隨著業(yè)務 邏軻變得F1益復雜。我們實在是被復雜的對象關系搞頭疼了，如果這時我們還要考慮如何把 數(shù)據(jù)存儲起來(通常的惜況卜是存到關系型數(shù)據(jù)庫中)，我們開始抱怨自己軟件的架構太惡 心，一團糟。面向對象設計思想教會我們一如果我們不想做這件事，就交給別人做吧！這 時聰明的架構師們提出了一個概念一持久化。如果我們在自己的應用中添加一個新的層 專門負責對彖狀態(tài)的持久化保存及同步，那不就可以全心全

4、意的“搞對象”了嗎？持久化 概念的產生,代表著我們對關系型數(shù)據(jù)庫的依賴降低了。因此茯至有人推斷數(shù)據(jù)庫已死。 同時，關系型數(shù)據(jù)庫這個新的概念也不斷形成，并演化成理論，又由理論衍生出產品。因此 一個盤識良好的程序員，至少應該認同，持久化并不是產品中最重要的環(huán)節(jié)一最重要的環(huán) 節(jié)是清晰正確的業(yè)務邏輯?；疑貛堑?，從理論上看，web三層架構很美了。但在實際開發(fā)產品的時候，我們發(fā)現(xiàn)了很多問 題。主要問題就是用UI層和業(yè)務層Z間有許第灰色地帶。這些灰色地帯業(yè)務邏輯層不想管, UI層也不想管。讓我們舉一些例子：例子1,難以管理的頁面跳轉關系上圖是我在講JSP課程時，一個簡單案例的頁面跳轉關系圖。這是一個十分

5、簡單的例子， 但頁面跳轉關系己經(jīng)挺復雜了。試想，如果你正在做一個有上百張表，十幾個核心模塊，兒 百個頁面的產品時.這張圖將變得務么以雜！而間題是.這些頁面跳轉關系分散/P JSP和 Servlet中，非常難以符理。例子2,表單數(shù)據(jù)的驗證及封裝：假設我們正在做一個簡單的表單提交，我們希塑對用戶數(shù)據(jù)的數(shù)據(jù)進行驗證和封裝，敲終交 給業(yè)務邏輯層一個實體對彖。從三層架構分析，我們想要做的那情是這樣的：瀏覽器端服務器端但是該把臉證和封裝數(shù)據(jù)的工作交給誰來做呢？ UI層還是業(yè)務邏輯層？都不太介適！例子3,國際化：如果我們想為不同國家和地區(qū)的人提供不同的語言，無疑需要國際化的支持。那么，我們需 要在JSP頁而

6、上根據(jù)用戶的配宜或請求信息判斷應該為該用戶呈現(xiàn)哪國文字。而這些判斷 和顯示的邏輯應該劃分到業(yè)務邏輯層還是UI層呢？用MVC的思路解決問題對于糾纏不清的問題，我們總要想辦法將其分解。MVC是一種設計思想。這種思想強調實 現(xiàn)模型(Model)、視圖(View)和控制器的分離。這種思想是如何作用于web的呢？實際上, 我們在web開發(fā)中引入MVC思想，想要達到的目的是：實現(xiàn)UI層利業(yè)務邏輯層分離 控制器是為了實現(xiàn)上述目的而存在的！在解決了持久化的問題后，我們發(fā)現(xiàn)，我們的所說的業(yè)務邏輯層和MVC中的Model指的 是一回事，我們所說的UI層和MVC屮的View是-回事。MVC提供了讓模型和視圖相分 離

7、的思路一引入控制器;我們把頁面跳轉關系管理、表單數(shù)據(jù)的封裝及驗證、國際化等任 務交給控制器處理。因此，也不難理解為什么流行的MVC框架都貝有管理頁面跳轉關系、 表單數(shù)據(jù)的封裝及驗證、國際化等特性。總結在Java web開發(fā)中，MVC框架充當了 UI層和業(yè)務邏輯層的適配器的作用。MVC框架實 現(xiàn)了 UI層和業(yè)務邏輯層繪人程度的分離。使用IIVC的好處，MVC使用規(guī)則,java三層架構設計思想java開發(fā)web應用MVC使用規(guī)則為了提供可甫用的設計及代碼，M-V-C之間的交互應該很好地定義，以及它們相互 間地依賴關系要盡量最小。使用MVC模式的其中一個目的就是，使-個單一的模型能與多個視圖及控制器

8、聯(lián)介 起來。MVC模型保證了視圖能與模型同步。當控制器從用戶輸入中接受:到一個有效的命令 后，它將調用模型上的相應方法。模型將確認該操作是否與當前的狀態(tài)一致，然后再執(zhí)行 它，并相應地修改視圖的狀態(tài)。而視圖，作為一個觀察者，將根據(jù)得到的模型狀態(tài)改變來 更新它的顯示。依賴關系保持最小為了使一個模型能在多個視圖及控制器中使用，它們之間的依賴關系必須保持最小。 要做到這些，必須遵守一下規(guī)則（如圖10-03）：注意：A依賴于E,表示A的代碼中需要與B相關的信息，如調用B的方法或使用 B的屬性。1、模型必須與視圖及控制器沒有任何依賴關系。2、視圖依賴于與它相關的模型，它必須知道模型狀態(tài)結構，這樣才能把模型

9、顯示出來。3、視圖不能依賴與控制器，這樣的訕，幾個不冋的控制器可以關聯(lián)相冋視圖。4、控制器依賴于相關的模型及視圖，模型定義了控制器能調用的方法，而視圖定義上卜關系，通過它控制器町以解釋用戶輸入信息。這使得控制器能緊緊地跟視圖聯(lián)系在一 起。圖10-03 MVC模式中允許的依賴關系交互必須保持最小另外一個需要使用多視圖及多控制器的前提務件就是保存最小的交互。特別是，控 制器一定不要直接影響與它相關聯(lián)的視圖的顯示。而是在用戶輸入產生的彫響在視圖中可 見之前，控制器必須與模型進行一個完整的往返交互，這樣能保證一個狀態(tài)修改能更新所 令的視圖，以及視圖能保持與模型同步。使用單一控制器的實現(xiàn)通常會違反這種規(guī)

10、則，因 為一些不夠嚴謹?shù)乃季S:“我己經(jīng)知道這個狀態(tài)修改要發(fā)生,所以不需要模型來告訴我這個”。但這是錯的，原因有三個：1、模型可能因為某些原因否決該操作，然后這個操作就不會發(fā)生了。2、其他控制器可能同時調用了該模型的操作，有些操作可能也會影響視圖的顯示,或者使操作不合法。3、另外，將來使用其他控制器來擴展這個實現(xiàn)也是可能的。MVC模式是"Model-View-Controller的縮寫,中文翻譯為“模式視圖控制器“。MVC應用程序總是由這三個部分組成。Event（事件）導致Controller改變Model 或View,或者同時改變兩者。只耍Controller改變了 Models的數(shù)

11、據(jù)或者屬性， 所有依賴的View都會自動更新。類似的，只要Controller改變T View, View 會從潛在的Model中獲取數(shù)據(jù)來刷新ABoMVC模式最早是Smalltalk語言研究 團提出的，應用丁用戶交互應用程序中。Smalltalk語言和java語言有很多相似 性，都是面向對象語言，很然的SUN在petstore（寵物店）事例應用程序中就推 薦MVC模式作為開發(fā)Web應用的架構模式。MVC模式是一種架構模式，其實 需要其他模式協(xié)作完成。在J2EE模式目錄中，通常采用service to worker模式 實現(xiàn)，而service to worker模式可由集中控制器模式,派遣器模

12、式和Page Helper 模式組成。而Struts只實現(xiàn)了 MVC的View和Controller兩個部分，Model部 分需要開發(fā)者自己來實現(xiàn)，Struts提供了抽象類Action使開發(fā)者能將Model應 用于Struts框架中。MVC模式是一個復雜的架構模式，其實現(xiàn)也顯得非常復雜。但是，我們 己經(jīng)終結出了很多可靠的設計模式，多種設計模式結合在一起，使MVC模式的 實現(xiàn)變得相對簡單易行o Views可以看作一棵樹，顯然可以用Composite Pattern 來實現(xiàn)。Views和Models之間的關系可以用Observer Pattern體現(xiàn)。Controller 控制Views的顯示,可

13、以用Strategy Pattern實現(xiàn)。Model通常是一個調停者, 可采用Mediator Pattern來實現(xiàn)?，F(xiàn)在讓我們來了解一下MVC三個部分在J2EE架構中處于什么位置，這 樣有助于我們理解MVC模式的實現(xiàn)。MVC與J2EE架構的對應關系是:View處 于Web Tier或者說是Client Tier,通常是JSP/Servlet,即頁而顯示部分。 Controller也處于Web Tier,通常用Servlet來實現(xiàn)，即頁而顯示的邏輯部分實 現(xiàn)。Model處于Middle Tier,通常用服務端的javaBean或者EJB實現(xiàn)，即業(yè) 務邏輯部分的實現(xiàn)。一、MVC設計思想MVC英文

14、即Model-View-Controller,即把一個應用的輸入、處理、輸出流程 按照Model、View、Controller的方式進行分離，這樣一個應用被分成三個層模型層、視圖層、控制層。視圖(View)代表用戶交互界而，對于Web應用來說，可以概括為HTML界面, 但有可能為XHTML、XML和Applet。隨著應用的復雜性和規(guī)模性，界面的處理 也變得具有挑戰(zhàn)性。一個應用可能有很多不同的視圖，MVC設計模式對于視圖 的處理僅限于視圖上數(shù)據(jù)的采集和處理，以及用戶的請求，而不包括在視圖上的 業(yè)務流程的處理。業(yè)務流程的處理交予模型(Model)處理。比如一個訂單的視圖 只接受來口模型的數(shù)據(jù)并顯

15、示給用戶，以及將用戶界而的輸入數(shù)據(jù)和請求傳遞給 控制和模型。模型(Model)：就是業(yè)務流程/狀態(tài)的處理以及業(yè)務規(guī)則的制定。業(yè)務流程的處 理過程對其它層來說是黑箱操作，模型接受視圖請求的數(shù)據(jù)，并返回最終的處理 結果。業(yè)務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是 一個典型的應用例子，它從應用技術實現(xiàn)的角度對模型做了進一步的劃分，以便 充分利用現(xiàn)有的組件，但它不能作為應用設計模型的框架。它僅僅告訴你按這種 模型設計就可以利用某些技術組件，從而減少了技術上的困難。對一個開發(fā)者來 說，就可以專注于業(yè)務模型的設計。MVC設計模式告訴我們，把應用的模型按 一定的規(guī)則抽取出來，抽収的層

16、次很重要，這乜是判斷開發(fā)人員是否優(yōu)秀的設計 依據(jù).抽象與貝體不能隔得太遠，也不能太近"MVC并沒有提供模型的設計方 法，而只告訴你應該組織管理這些模型，以便T模型的重構和提高重用性。我們 可以用對象編程來做比喻，MVC定義了一個頂級類，告訴它的子類你只能做這 些，但沒法限制你能做這些。這點對編程的開發(fā)人員非常重要。業(yè)務模型還有一個很重要的模型那就是數(shù)據(jù)模型。數(shù)據(jù)模型主要指實體對象的 數(shù)據(jù)保存（持續(xù)化）。比如將一張訂單保存到數(shù)據(jù)庫，從數(shù)據(jù)庫獲取訂單。我 們可以將這個模型單獨列出，所有有關數(shù)據(jù)庫的操作只限制在該模型中?？兀–ontroller）可以理解為從用戶接收請求，將模型與視圖匹配在

17、一起，共同 完成用戶的請求。劃分控制層的作用也很明顯，它清楚地告訴你，它就是一個分 發(fā)器，選擇什么樣的模型，選擇什么樣的視圖，可以完成什么樣的用戶請求?？?制層并不做任何的數(shù)據(jù)處理。例如，用戶點擊一個連接，控制層接受請求后，并 不處理業(yè)務信息，它只把用戶的信息傳遞給模型，告訴模型做什么，選擇符合要 求的視圖返回給用戶。因此，一個模型可能對應多個視圖，一個視圖可能對應多 個模型。模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通 過某個視圖的控制器改變了模型的數(shù)據(jù)，所有其它依賴于這些數(shù)摒的視圖都應反 映到這些變化。因此，無論何時發(fā)生了何種數(shù)據(jù)變化，控制器都會將變化通知所 有的

18、視圖，導致顯示的更新。這實際上是一種模型的變化傳播機制。模型、視 圖、控制器三者之間的關系和各自的主要功能，如圖1所示。一、MVC設計模式的實現(xiàn)ASP.NET提供了一個很好的實現(xiàn)這種經(jīng)典設計模式的類似環(huán)境。開發(fā)者通過 在ASPX頁而中開發(fā)用戶接口來實現(xiàn)視圖；控制器的功能在邏輯功能代碼（.cs） 中實現(xiàn)；模型通常對應應用系統(tǒng)的業(yè)務部分。在ASP.NET中實現(xiàn)這種設計而提 供的一個多層系統(tǒng)，較經(jīng)典的ASP結構實現(xiàn)的系統(tǒng)來說有明顯的優(yōu)點。將用戶 顯示（視圖）從動作（控制器）中分離出來，提高了代碼的重用性。將數(shù)據(jù)（模 型）從對其操作的動作（控制器）分離出來可以讓你設計一個與后臺存儲數(shù)據(jù)無 關的系統(tǒng)。就

19、MVC結構的本質而言，它是一種解決耦合系統(tǒng)問題的方法。2.1視圖視圖是模型的表示，它提供用戶交互界面。使用多個包含單顯示頁面的用戶部 件，復雜的Web頁面可以展示來H多個數(shù)據(jù)源的內容，并且網(wǎng)頁人員，美工能 獨自參與這些Web頁面的開發(fā)和維護。在ASP.NET下，視圖的實現(xiàn)很簡單?？梢韵耖_發(fā)WINDOWS界面一樣直接 在集成開發(fā)環(huán)境下通過拖動控件來完成頁面開發(fā)本。本文中介紹每一個頁面都采 用復合視圖的形式即：一個頁面由多個子視圖（用戶部件）組成；子視圖可以是最 簡單HTML控件、服務器控件或多個控件嵌套構而成的Web自定義控件。頁面 都由模板定義，模板定義了頁面的布局，用戶部件的標簽和數(shù)目，用戶

20、指定一個 模板，平臺根據(jù)這些信息自動創(chuàng)建頁而。針對靜態(tài)的模板內容，如頁面上的站點 導航，菜單，友好鏈接，這些使用缺省的模板內容配置；針對動態(tài)的模板內容（主 要是業(yè)務內容），由于用戶的請求不同，只能使用后期綁定，并且針對用戶的不 同，用戶部件的顯示內容進行過濾。使用由用戶部件根據(jù)模板配置組成的組合頁 面，它增強了可重用性，并原型化了站點的布局。視圖部分大致處理流程如下：首先，頁而模板定義了頁而的布局；頁而配置文 件定義視圖標簽的具體內容（用戶部件）；然后，由頁面布局策略類初始化并加 載頁面；每個用戶部件根據(jù)它F1己的配置進行初始化，加載校驗器并設置參數(shù)， 以及事件的委托等：用戶提交后，通過了表示

21、層的校驗，用戶部件把數(shù)據(jù)自動提 交給業(yè)務實體即模型。這一部分主要定義了 WEB頁面基類PageBase；頁面布局策略類 PageLayout,完成頁面布局，用于加載用戶部件到頁而：用戶部件基類 UserControlBase BP用戶部件框架，用于動態(tài)加載檢驗部件，以及實現(xiàn)用戶部件 的個性化。為了實現(xiàn)WEB應用的靈活性，視圖部分也用到了許多配置文件例如: 置文件有模板配置、頁面配置、路徑配置、驗證配置等。2.2控制器為了能夠控制和協(xié)調每個用戶跨越多個請求的處理，控制機制應該以集中的方 式進行管理。因此，為了達到集中管理的目的引入了控制器。應用程序的控制器 集中從客戶端接收請求（典型情況下是一個

22、運行瀏覽器的用戶），決定執(zhí)行什么 商業(yè)邏輯功能，然后將產生下一步用戶界而的責任委派給一個適當?shù)囊晥D組件。用控制器提供一個控制和處理請求的集中入口點，它負責接收、截取并處理用 戶請求；并將請求委托給分發(fā)者類，根據(jù)當前狀態(tài)和業(yè)務操作的結果決定向客戶 呈現(xiàn)的視圖"在這一部分主耍定義了 HttpReqDispatcher（分發(fā)者類）、 HttpCapture（請求捕獲者類）、Controller（控制器類）等，它們相互配合來完成控制 器的功能。請求捕獲者類捕獲HTTP請求并轉發(fā)給控制器類。控制器類是系統(tǒng) 中處理所有請求的最初入口點?？刂破魍瓿梢恍┍匾奶幚砗蟀颜埱笪薪o分發(fā) 者類；分發(fā)者類分

23、發(fā)者負責視圖的管理和導航，它管理將選擇哪個視圖提供給用 戶，并提供給分發(fā)資源控制。在這一部分分別采用了分發(fā)者、策略、工廠方法、 適配器等設計模式。為了使請求捕獲者類自動捕獲用戶請求并進行處理，ASP.NET提供低級別的 請求/響應API,使開發(fā)人員能夠使用.NET框架類為傳入的HTTP請求提供 服務。為此，必須創(chuàng)作支持System.Web.lHTTPHandler接口和實現(xiàn) ProcessRequest（）方法的類即：請求捕獲者類，并在web.config的< httphandlers>節(jié)中添加類。ASP.NET收到的每個傳入HTTP請求最終由實 現(xiàn)IHTTPHandler的類的特

24、定實例來處理。IHttpHandlerFactory提供了處理 IHttpHandler實例URL請求的實際解析的結構。HTTP處理程序和工廠在 ASP.NET配置中聲明為web.config文件的一部分。ASP.NET定義了一個V httphandlers>配置節(jié)，在其中可以添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory和HttpHandler的設置。HTTP處理程序和工廠是 ASP.NET頁框架的主體。工廠將每個請求分配給一個處理程序，后者處理該請 求。例如，在全局machine.config文件中，ASP.NET將所有對ASPx文件 的請求映射到Http

25、Capture類:<httphandlers></httphandlers>2.3模型MVC系統(tǒng)中的模型從概念上可以分為兩類一一系統(tǒng)的內部狀態(tài)和改變系統(tǒng)狀 態(tài)的動作。模型是你所有的商業(yè)邏輯代碼片段所在。本文為模型提供了業(yè)務實體 對象和業(yè)務處理對象：所有的業(yè)務處理對象都是從ProcessBase類派生的子類。 業(yè)務處理對象封裝了具體的處理邏輯，調用業(yè)務邏輯模型，并且把響應提交到合 適的視圖組件以產生響應。業(yè)務實體對象可以通過定義屬性描述客戶端表單數(shù) 據(jù)。所有業(yè)務實體對象都EntityBase派生子類對象，業(yè)務處理對象可以直接對 它進行讀寫，而不再需耍和requests r

26、esponse對象進彳亍數(shù)據(jù)交互。通過業(yè)務實 體對象實現(xiàn)了對視圖和模型之間交互的支持。實現(xiàn)時把”做什么“（業(yè)務處理）和 ”如何做“（業(yè)務實體）分離。這樣可以實現(xiàn)業(yè)務邏輯的重用。由于各個應用的具 體業(yè)務是不同的，這里不再列舉苴具體代碼實例。三、MVC設計模式的擴展通過在ASP.NET中的MVC模式編寫的，具有極其良好的可擴展性。它可以 輕松實現(xiàn)以下功能： 實現(xiàn)一個模型的多個視圖； 采用多個控制器： 當模型改變時，所有視圖將自動刷新： 所有的控制器將相互獨立工作。這就是MVC模式的好處，只需在以前的程序上稍作修改或增加新的類，即可 輕松增加許多程序功能。以前開發(fā)的許多類可以重用，而程序結構根本不再

27、需要 改變，各類之間相互獨立，便于團體開發(fā)，提高開發(fā)效率。下面討論如何實現(xiàn)一 個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變, 與前面的完全一樣，這就是面向對象編程的好處。對于控制器中的類，只需要增 加另一個視圖，并與模型發(fā)生關聯(lián)即可。該模式下視圖、控制器、模型三者之間 的示意圖如圖2所示。同樣也可以實現(xiàn)其它形式的MVC例如：一個模型、兩個視圖和兩個控制器。 從上面可以看出，通過MVC模式實現(xiàn)的應用程序具有極其良好的可擴展性，是 ASP.NET而向對象編程的未來方向。四、MVC的優(yōu)點大部分用過程語言比如ASP、PHP開發(fā)出來的Web應用，初始的開發(fā)模板 就是混合層的數(shù)據(jù)編

28、程。例如，直接向數(shù)擄庫發(fā)送請求并用HTML顯示,開發(fā)速 度往往比較快，但由丁數(shù)據(jù)頁面的分離不是很直接，因而很難體現(xiàn)出業(yè)務模型的樣 子或者模型的重用性。產品設計彈性力度很小，很難滿足用戶的變化性需求。 MVC要求對應用分層，雖然要花費額外的工作，但產品的結構清晰，產品的應 用通過模型可以得到更好地體現(xiàn)。冇先，最重要的是應該有多個視圖對應一個模型的能力。在目前用戶需求的快 速變化下，可能有多種方式訪問應用的要求。例如，訂單模型可能有本系統(tǒng)的訂 單，也有網(wǎng)上訂單，或者其他系統(tǒng)的訂單，但對于訂單的處理都是一樣，也就是 說訂單的處理是一致的。按MVC設計模式，一個訂單模型以及多個視圖即可解 決問題。這樣

29、減少了代碼的復制，即減少了代碼的維護量，一旦模型發(fā)生改變， 也易于維護。其次，由于模型返回的數(shù)據(jù)不帶任何顯示格式，因而這些模型也 可直接應用于接口的使用。再次，由于一個應用被分離為三層，因此有時改變其中的一層就能滿足應用的 改變。一個應用的業(yè)務流程或者業(yè)務規(guī)則的改變只需改動MVC的模型層。控制層的概念也很有效，由于它把不同的模型和不同的視圖組合在一起完成不 同的請求，因此，控制層可以說是包含了用戶請求權限的概念。最后，它還有利于軟件工程化管理。由于不同的層各司其職，每一層不同的應 用具有某些相同的特征，有利于通過工程化、工具化產生管理程序代碼。五、MVC的不足MVC的不足體現(xiàn)在以下幾個方面：(

30、1) 增加了系統(tǒng)結構和實現(xiàn)的復雜性。對于簡單的界而，嚴格遵循MVC,使 模型、視圖與控制器分離，會增加結構的復雜性，并可能產生過多的更新操作， 降低運行效率。(2) 視圖與控制器間的過于緊密的連接。視圖與控制器是相互分離，但確實 聯(lián)系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣 就妨礙了他們的獨立重用。(3) 視圖對模型數(shù)據(jù)的低效率訪問。依據(jù)模型操作接口的不同，視圖可能需 要多次調用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問，也將 損害操作性能。(4) 目前，一般高級的界而工具或構造器不支持MVC模式。改造這些工具 以適應MVC需要和建立分離的部件的代價是很高

31、的，從而造成使用MVC的困 難.自己理解的J2EE三層架構（與軟件設計模式的聯(lián)系區(qū)別）（2009-04-13 09:37:50）轉載標簽:軟件設計模式dao12ee雜談J2EE Overview如上圖1.J2EE 分 3 層：服務器端業(yè)務邏紺（有業(yè)務邏輯層和持久化數(shù)據(jù)層.Busuiness Tier lEISTier）.服務器端 表示層（WebTier）及客戶端表示層（ClientTiei）町以將J2EE設計模式歸納到6個類別（1）表示層體系結構模式（服務器端表示層）3前端控制器模式b.MVC模式C.裝飾器模式（2）表示層高級體系結構模式a. 復介視圖模式（在服務器端表示層）b. 視圖助手模式

32、c. 服務工作者模式（3）表示層伸縮性模式（服務器端表示層）九異步頁面模式b. 緩存過濾器模式c. 資源池模式（4）業(yè)務層模式（服務器端業(yè)務邏輯層）a. 復合丈體模式b. 域對象模式（業(yè)務數(shù)據(jù)層）（5）數(shù)據(jù)傳遞模式（用于業(yè)務邏輯層和表示層之間）a. DTO模式b. DTO傳遞散列模式c. 數(shù)據(jù)庫行集介DTO模式（6）數(shù)據(jù)庫模式（服務器持久化數(shù)據(jù)層）a. DAO模式b. DAO工廠模式2 .前端控制器模式常用的應用為，一個servlet作為一個前端控制器，它負責根據(jù)頁面的請求，然后轉發(fā)到頁 面控制器.頁面控制器也是一個servlet,這個servlet電泳關于這個請求所應詒執(zhí)行的業(yè)務 邏知，并根

33、據(jù)業(yè)務邏輯的結果返回到具體的現(xiàn)實頁面。簡化的使用是前端控制器servlet利 用“命令模式”將頁而控制器轉化成一個個更細粒度的類。AcitonSeivlet是前端控制器，部分代碼RequestUtils.selecetModule（request.getServrletContext（）; getRequestProcessor（getModuleConfig（request）.process（iequest4espoiise）;RequestProcessor的process方法處理公共任務，部分代碼 if（?pfocessPieprocess（iequestjespoiise）return

34、;piocessXXX方法都在處理公共的動作RequestProcessor的piocessActioiiPerform方法實現(xiàn)命令模式，該方式將A體請求的動作分配 到 Action o部分代碼renm（action.execute（mappmg.fbnn.request,response）;前端控制器選擇頁面控制器解析用戶的請求，實現(xiàn)具體業(yè)務邏輯，并根據(jù)結果轉發(fā)到頁面試 圖3. 裝飾器模式(1) 設計模式的的裝飾器模式裝飾器模式為客戶端提供一個透明擴充某實例功能的方法，該方法的返回類型就是這個實 例，在客戶端不斷調用這個方法的同時，該實例的內部表彖已經(jīng)隨著功能改變完全不同。(2) J2EE設

35、計模式中的裝飾器模式Servlet支持裝飾器模式，裝飾一個request請求，利用裝飾器類截獲所有發(fā)送給目標對彖的 請求，并執(zhí)行需要的工作，完成之后再把請求轉發(fā)到下一個裝飾器，知道沒有了裝飾器，最 后將請求發(fā)送到SendetSendet利過濾器來攔截請求和響應，在請求到達Senlet前，為這個請求做一個些額外處理。 處理器可以被看成一個鍛，每個過濾器之間都能互相傳遞，以卜是過濾器Filter接II的 doFilter4il個參數(shù) SeivletRRequest,SeivletResponseJilterCliam.利用 FilterCliain 的 doF山 激活下一個相關的過濾器public

36、 void doFilter(Sen4etRequest requestSendctResponse response.FilteiChamchain)tluows IOException.SenrletException用secletEncoding方法設置字符編碼if(iDgnore request.getChaiacterEncodmgQ = null)Suing encoding = selcctEncoduig(iequest);if(eQCoding != null)request.setCliaracterEncodmg(encodmg);cliain.doFiltef(xequ

37、est,response);4. 復合視圖模式設計模式中的“合成模式”合成模式:提供個樹狀的対象給構，樹枝類與樹葉類都實現(xiàn)同個接II，以便客戶端在調用任何對象時都只要需要調用該樹狀結構的根接口就可以了。J2EE設計模式中的“復合視圖模式”將視圖的布局從中抽離出來，形成由一系列通用組件的模板?？梢岳肵ML來描述視圖的 組成5. 視圖助手模式jsp頁面的標簽庫和stmts的標簽庫,一個標簽應該繼承javax.servlet.jsp.tagext.TagSupport, 并給出doStaiTag和doEndTag兩個方法的實現(xiàn)。doStaiTag實現(xiàn)業(yè)務邏輯doEndTag控制輸出6. 服務工作者

38、模式將頁面流轉、前端控制器模式，視圖助于模式合在一起使用，表示“諸求-轉發(fā)-視圖”的一整 套流程。該模式也是MVC模式的實現(xiàn)標準，struts也基于這個模式實現(xiàn)7. 異步頁而模式肖遠程數(shù)據(jù)發(fā)生變化時，將其緩存下來，稱為“發(fā)布者訂閱者模型”。在J2EE的功能是， 利用一個訂閱者角色，在一個的時間間隔攻數(shù)據(jù)發(fā)牛變化時，接受來自發(fā)布者也色的數(shù)據(jù), 訂閱者角色同時會利用模式曾來更新數(shù)據(jù)庫。這樣的工作累世于軟件設計模式中的“觀察者 模式”。常見的應用為，當發(fā)布服務器需要顯示最新信息的HTML頁面時，會利用一個訂閱 者角色來負貞。例如ActionSendet8. 緩存過濾器模式這個模式用來椽村動態(tài)產生的頁

39、面，盡可能減少覓復生成的頁面。在J2EE的功能是，利用 一個緩存過濾器截獲請求，判斷該請求所返回的頁面是否有緩存。緩存過濾器應該放在“裝 飾過濾器"和工作Servlet之前。緩存過濾器是裝飾過濾器的一個變體。対 HTTPSeivletResponse對彖進行裝飾來保存請求處理的結果。9. 資源池模式客戶端在需要JDBC連接時，應該從一個池中去取得。如果池中有町用的JDBC連接，則返 回這一對象資源。如果沒有任何可用資源，但池中還有容量，就使用工廠生成一個新的實例。 如果池中沒有任何町用資源H池的容星已經(jīng)沾滿，那就必須等待，知道其他客戶端還回至少 一個對象。10. 復合實體模式該模式可

40、以降低工作環(huán)境中的復雜性和通信開銷。一個笑介實體將來自齊種不同來源的數(shù)據(jù) 集中到一個單獨的對象中。應用為EJB環(huán)境的集中對象。11. 域對象模式將一張數(shù)據(jù)庫中的表結構對象化，例如hibemate中的表轉化成對象，使用在持久層框架理 論中12. DTO模式stmts的ActionFoim就是一個DTO模式的實現(xiàn)，從頁面視圖得到數(shù)據(jù)傳遞給模型層，模型 層通過業(yè)務邏輯的調用后將返還數(shù)據(jù)給AchonFonn用作視圖層的數(shù)據(jù)顯示AEonFonn僅僅被用在從視圖層傳遞到模型層。13. DTO散列模式stmts的DvnaActioiiFoim就是一個DTO散列模式，讓程序員設置某個數(shù)據(jù)的主鍵，而后在 Act

41、on中可以通過該主鍵得到頁面數(shù)據(jù)14. 數(shù)據(jù)庫行集合DTO模式將JDBC的ResultSet發(fā)送到客戶端顯示，使用ResultSet接【I的一個獨立類作為DTO發(fā)送 到客戶端顯示。15. DAO模式數(shù)據(jù)訪問對象模式被認為是持久層的一種基本模式DAO模式有反問數(shù)據(jù)和處理業(yè)務邏輯的功能，現(xiàn)在不再流行16. DAO工廠模式用戶只對被創(chuàng)建的產品感興趣，而這些被創(chuàng)建的產品在創(chuàng)建Z前所做的許多額外的工作被時 裝到工廠接【I的子類中，而不適用貝體產品類的構造函數(shù)，達到隱式的使用改模式只冇和數(shù)據(jù)庫連接的功能，沒冇實現(xiàn)訪問數(shù)據(jù)的功能17J2EE設計模式與設計模式的區(qū)別（1）軟件設計模式是設計，J2EE設計模式關

42、注的就是構架（2）軟件設計模式為了解決各種軟件世界中常見問題提煉的一種最佳時間，是許多經(jīng)驗豐 富的軟件設計者不斷成功和失敗的總結。J2EE模式為了解決企業(yè)級應用的構架問題。（3）軟件設計模式的主要目的是解耦，可以在J2EE模型的任何層中出現(xiàn)軟件設計模式。 J2EE設計模式對于J2EE模型中的分層進行解耦。軟件設計模式關注的是微觀的方法學， J2EE設計模式則是宏觀的方法學。18.（1）前端控制器模式、MVC模式、服務工作者模式被整合成了表示層框架，如stmts框架, webwork 框架（2）復合視圖模式有Tiles框架實現(xiàn)（3）視圖助手模式的主要實現(xiàn)是標簽庫，JSTL標簽庫（4）DAO工廠模

43、式隨著中間層框架Spring的依賴注入，已經(jīng)不一定需要實現(xiàn)。F而摘自網(wǎng)友的文章：一、MVC架構Stmts是一個不錯的MVC架構，我一直以來都用它，通過簡單的配豊即可將view,controler, 和Model結合起來。View主要以JSP來實現(xiàn)，因為它是面向標簽的，所以對于網(wǎng)頁設計人 員提供了很好的接II。ForniBean 介于JSP和Action Z間的中間數(shù)據(jù)載體，它肩負著數(shù)據(jù) 從JSP到ACTION的傳遞過程。Acuon是流程的中轉站，不同的業(yè)務在不同的Acuon中以 不冋的Model調用來實現(xiàn)。Model就足實現(xiàn)貝體業(yè)務的操作過程，不過這種過程足一種在較 高水平上的實現(xiàn)。總之，MV

44、C架構實現(xiàn)了三層結構中的兩層，即表現(xiàn)層和業(yè)務層，另外還有一層被稱之為持 久化層。二、三層架構正如以上所說的，三層架構即“表現(xiàn)層”，“業(yè)務層”，“持久化層”。表現(xiàn)層實現(xiàn)的代表作品是 Stmts框架，業(yè)務層實現(xiàn)的代表作晶是Sprmg,持久層實現(xiàn)的代表作品是Hibernate °不過在 我的開發(fā)Spring被省掉了，因為我認為業(yè)務過丁簡單，還不至于用Spring 實現(xiàn)。卜而 我將具體的來說說我的三層實現(xiàn)。1、三種Bean在我的實現(xiàn)中，總共有三種Eean,它們都是為保存對象狀態(tài)而存在的。持久層中，這種Eean 就是POJO對彖。它是面向數(shù)據(jù)庫的，或者說多少得照顧到數(shù)據(jù)庫的實現(xiàn)，岡為我習慣于用

45、 PoweiDesigner來設計數(shù)據(jù)庫，做出來的結構也是比較中規(guī)中矩的，而如果直接用Hibemate 來實數(shù)據(jù)庫的話，就不那么干凈了。所以POJO對彖的設計就不能完全面向對象。業(yè)務層中 的Beau我把它稱之為Emily,這是一個完全面向程序邏輯的Bcan«它可能是好幾個POJO的 集合。對于業(yè)務邏輯來，這種被稱之為Entity的Eean做到了“拿來就用”，很便于業(yè)務的進 行。在顯示層中的Bean就是FoiniBean T主要用于傳入數(shù)據(jù)所用。POJO僅生存于持久化層，到了業(yè)務層就將數(shù)據(jù)交給Entity T o而Entity不僅生存于業(yè)務層, 它還被傳到了 JSP中，用于顯示。2、P

46、qjo 與 Dao我認為這是數(shù)據(jù)與操作的關系，Dao只在呼操作，而Pojo僅用于保存數(shù)據(jù)。卜面是我Dao 接口的實個現(xiàn)。public mterface Dao /Ipublic void resetPO(Pojo pojo) tliis.userPo = (UserPo)pojo;public Suing save() Stimg oid null;try/Session session = HibernateUtil.cunentSessionQ 己經(jīng)被提至構造函數(shù)中初始化 了Transaction tx = session. beginT raiisac tion();if (useiPo

47、.getldO = null) oid = (Sumg)session.save(userPo)/ 如果這是一個新的pojo 則進行 insert 操作。session.flush();mit();elsesession.update(userPo,userPo.getIdQ)y/ 如果該 pojo 己被初始化過則進 ljupdate 操作session.flush();tx.conumt(); catch(Hibernate Exception ex)System.out.println(7An UserDao.saveQ出現(xiàn)異常！ ”)；log.enor(MUseiDao.save()出現(xiàn)異常！ ",ex);return oid;public Pojo load。UserPo tmp = new UserPo();try/Session ses