三層架構(gòu)和MVC模式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29、減少了代碼的復(fù)制，即減少了代碼的維護(hù)量，一旦模型發(fā)生改變， 也易于維護(hù)。其次，由于模型返回的數(shù)據(jù)不帶任何顯示格式，因而這些模型也 可直接應(yīng)用于接口的使用。再次，由于一個(gè)應(yīng)用被分離為三層，因此有時(shí)改變其中的一層就能滿(mǎn)足應(yīng)用的 改變。一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需改動(dòng)MVC的模型層?？刂茖拥母拍钜埠苡行В捎谒巡煌哪Ｐ秃筒煌囊晥D組合在一起完成不 同的請(qǐng)求，因此，控制層可以說(shuō)是包含了用戶(hù)請(qǐng)求權(quán)限的概念。最后，它還有利于軟件工程化管理。由于不同的層各司其職，每一層不同的應(yīng) 用具有某些相同的特征，有利于通過(guò)工程化、工具化產(chǎn)生管理程序代碼。五、MVC的不足MVC的不足體現(xiàn)在以下幾個(gè)方面：(

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

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

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

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

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

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

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

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

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

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

40、以降低工作環(huán)境中的復(fù)雜性和通信開(kāi)銷(xiāo)。一個(gè)笑介實(shí)體將來(lái)自齊種不同來(lái)源的數(shù)據(jù) 集中到一個(gè)單獨(dú)的對(duì)象中。應(yīng)用為EJB環(huán)境的集中對(duì)象。11. 域?qū)ο竽Ｊ綄⒁粡垟?shù)據(jù)庫(kù)中的表結(jié)構(gòu)對(duì)象化，例如hibemate中的表轉(zhuǎn)化成對(duì)象，使用在持久層框架理 論中12. DTO模式stmts的ActionFoim就是一個(gè)DTO模式的實(shí)現(xiàn)，從頁(yè)面視圖得到數(shù)據(jù)傳遞給模型層，模型 層通過(guò)業(yè)務(wù)邏輯的調(diào)用后將返還數(shù)據(jù)給AchonFonn用作視圖層的數(shù)據(jù)顯示AEonFonn僅僅被用在從視圖層傳遞到模型層。13. DTO散列模式stmts的DvnaActioiiFoim就是一個(gè)DTO散列模式，讓程序員設(shè)置某個(gè)數(shù)據(jù)的主鍵，而后在 Act

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

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

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

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

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

46、qjo 與 Dao我認(rèn)為這是數(shù)據(jù)與操作的關(guān)系，Dao只在呼操作，而Pojo僅用于保存數(shù)據(jù)。卜面是我Dao 接口的實(shí)個(gè)現(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)被提至構(gòu)造函數(shù)中初始化 了Transaction tx = session. beginT raiisac tion();if (useiPo

47、.getldO = null) oid = (Sumg)session.save(userPo)/ 如果這是一個(gè)新的pojo 則進(jìn)行 insert 操作。session.flush();mit();elsesession.update(userPo,userPo.getIdQ)y/ 如果該 pojo 己被初始化過(guò)則進(jìn) 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