這個比較復(fù)雜,主要要看MVC分層功能。

成都創(chuàng)新互聯(lián)為企業(yè)級客戶提高一站式互聯(lián)網(wǎng)+設(shè)計服務(wù),主要包括成都網(wǎng)站設(shè)計、網(wǎng)站制作、APP應(yīng)用開發(fā)、微信小程序開發(fā)、宣傳片制作、LOGO設(shè)計等,幫助客戶快速提升營銷能力和企業(yè)形象,創(chuàng)新互聯(lián)各部門都有經(jīng)驗豐富的經(jīng)驗,可以確保每一個作品的質(zhì)量和創(chuàng)作周期,同時每年都有很多新員工加入,為我們帶來大量新的創(chuàng)意。
M代表Model層,業(yè)務(wù)邏輯封裝層;java中可以使用javabean實現(xiàn)。
V代表View層,視圖顯示層;可以實現(xiàn)JSP+Html實現(xiàn)。
C代表Control層,控制層;可以使用Servlet來實現(xiàn)。
其實理解了上述三個邏輯關(guān)系,就可以自己寫個MVC框架,比如mybatis,structs等基本思想都是這樣。
答案來自藍(lán)貴婚慶,12年婚慶、開業(yè)慶典策劃公司的系統(tǒng)管理軟件開部,張小工程師。
MVC模式是"Model-View-Controller"的縮寫,中文翻譯為"模式-視圖-控制器"。MVC應(yīng)用程序總是由這三個部分組成。Event(事件)導(dǎo)致Controller改變Model或View,或者同時改變兩者。只要Controller改變了Models的數(shù)據(jù)或者屬性,所有依賴的View都會自動更新。類似的,只要Controller改變了View,View會從潛在的Model中獲取數(shù)據(jù)來刷新自己。MVC模式最早是smalltalk語言研究團(tuán)提出的,應(yīng)用于用戶交互應(yīng)用程序中。smalltalk語言和java語言有很多相似性,都是面向?qū)ο笳Z言,很自然的SUN在petstore(寵物店)事例應(yīng)用程序中就推薦MVC模式作為開發(fā)Web應(yīng)用的架構(gòu)模式。MVC模式是一種架構(gòu)模式,其實需要其他模式協(xié)作完成。在J2EE模式目錄中,通常采用service to worker模式實現(xiàn),而service to worker模式可由集中控制器模式,派遣器模式和Page Helper模式組成。而Struts只實現(xiàn)了MVC的View和Controller兩個部分,Model部分需要開發(fā)者自己來實現(xiàn),Struts提供了抽象類Action使開發(fā)者能將Model應(yīng)用于Struts框架中。
MVC模式是一個復(fù)雜的架構(gòu)模式,其實現(xiàn)也顯得非常復(fù)雜。但是,我們已經(jīng)總結(jié)出了很多可靠的設(shè)計模式,多種設(shè)計模式結(jié)合在一起,使MVC模式的實現(xiàn)變得相對簡單易行。Views可以看作一棵樹,顯然可以用Composite Pattern來實現(xiàn)。Views和Models之間的關(guān)系可以用Observer Pattern體現(xiàn)。Controller控制Views的顯示,可以用Strategy Pattern實現(xiàn)。Model通常是一個調(diào)停者,可采用Mediator Pattern來實現(xiàn)。
現(xiàn)在讓我們來了解一下MVC三個部分在J2EE架構(gòu)中處于什么位置,這樣有助于我們理解MVC模式的實現(xiàn)。MVC與J2EE架構(gòu)的對應(yīng)關(guān)系是:View處于Web Tier或者說是Client Tier,通常是JSP/Servlet,即頁面顯示部分。Controller也處于Web Tier,通常用Servlet來實現(xiàn),即頁面顯示的邏輯部分實現(xiàn)。Model處于Middle Tier,通常用服務(wù)端的javaBean或者EJB實現(xiàn),即業(yè)務(wù)邏輯部分的實現(xiàn)。
一、MVC設(shè)計思想
MVC英文即Model-View-Controller,即把一個應(yīng)用的輸入、處理、輸出流程按照Model、View、Controller的方式進(jìn)行分離,這樣一個應(yīng)用被分成三個層——模型層、視圖層、控制層。
視圖(View)代表用戶交互界面,對于Web應(yīng)用來說,可以概括為HTML界面,但有可能為XHTML、XML和Applet。隨著應(yīng)用的復(fù)雜性和規(guī)模性,界面的處理也變得具有挑戰(zhàn)性。一個應(yīng)用可能有很多不同的視圖,MVC設(shè)計模式對于視圖的處理僅限于視圖上數(shù)據(jù)的采集和處理,以及用戶的請求,而不包括在視圖上的業(yè)務(wù)流程的處理。業(yè)務(wù)流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數(shù)據(jù)并顯示給用戶,以及將用戶界面的輸入數(shù)據(jù)和請求傳遞給控制和模型。
模型(Model):就是業(yè)務(wù)流程/狀態(tài)的處理以及業(yè)務(wù)規(guī)則的制定。業(yè)務(wù)流程的處理過程對其它層來說是黑箱操作,模型接受視圖請求的數(shù)據(jù),并返回最終的處理結(jié)果。業(yè)務(wù)模型的設(shè)計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應(yīng)用例子,它從應(yīng)用技術(shù)實現(xiàn)的角度對模型做了進(jìn)一步的劃分,以便充分利用現(xiàn)有的組件,但它不能作為應(yīng)用設(shè)計模型的框架。它僅僅告訴你按這種模型設(shè)計就可以利用某些技術(shù)組件,從而減少了技術(shù)上的困難。對一個開發(fā)者來說,就可以專注于業(yè)務(wù)模型的設(shè)計。MVC設(shè)計模式告訴我們,把應(yīng)用的模型按一定的規(guī)則抽取出來,抽取的層次很重要,這也是判斷開發(fā)人員是否優(yōu)秀的設(shè)計依據(jù)。抽象與具體不能隔得太遠(yuǎn),也不能太近。MVC并沒有提供模型的設(shè)計方法,而只告訴你應(yīng)該組織管理這些模型,以便于模型的重構(gòu)和提高重用性。我們可以用對象編程來做比喻,MVC定義了一個頂級類,告訴它的子類你只能做這些,但沒法限制你能做這些。這點對編程的開發(fā)人員非常重要。
業(yè)務(wù)模型還有一個很重要的模型那就是數(shù)據(jù)模型。數(shù)據(jù)模型主要指實體對象的數(shù)據(jù) 保存(持續(xù)化)。比如將一張訂單保存到數(shù)據(jù)庫,從數(shù)據(jù)庫獲取訂單。我們可以將這個模型單獨列出,所有有關(guān)數(shù)據(jù)庫的操作只限制在該模型中。
控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起,共同完成用戶的請求。劃分控制層的作用也很明顯,它清楚地告訴你,它就是一個分發(fā)器,選擇什么樣的模型,選擇什么樣的視圖,可以完成什么樣的用戶請求。控制層并不做任何的數(shù)據(jù)處理。例如,用戶點擊一個連接,控制層接受請求后, 并不處理業(yè)務(wù)信息,它只把用戶的信息傳遞給模型,告訴模型做什么,選擇符合要求的視圖返回給用戶。因此,一個模型可能對應(yīng)多個視圖,一個視圖可能對應(yīng)多個模型。
模型、視圖與控制器的分離,使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數(shù)據(jù),所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此,無論何時發(fā)生了何種數(shù)據(jù)變化,控制器都會將變化通知所有的視圖,導(dǎo)致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能,如圖1所示。
二、MVC設(shè)計模式的實現(xiàn)
ASP.NET提供了一個很好的實現(xiàn)這種經(jīng)典設(shè)計模式的類似環(huán)境。開發(fā)者通過在ASPX頁面中開發(fā)用戶接口來實現(xiàn)視圖;控制器的功能在邏輯功能代碼(.cs)中實現(xiàn);模型通常對應(yīng)應(yīng)用系統(tǒng)的業(yè)務(wù)部分。在ASP.NET中實現(xiàn)這種設(shè)計而提供的一個多層系統(tǒng),較經(jīng)典的ASP結(jié)構(gòu)實現(xiàn)的系統(tǒng)來說有明顯的優(yōu)點。將用戶顯示(視圖)從動作(控制器)中分離出來,提高了代碼的重用性。將數(shù)據(jù)(模型)從對其操作的動作(控制器)分離出來可以讓你設(shè)計一個與后臺存儲數(shù)據(jù)無關(guān)的系統(tǒng)。就MVC結(jié)構(gòu)的本質(zhì)而言,它是一種解決耦合系統(tǒng)問題的方法。
2.1 視圖
視圖是模型的表示,它提供用戶交互界面。使用多個包含單顯示頁面的用戶部件,復(fù)雜的Web頁面可以展示來自多個數(shù)據(jù)源的內(nèi)容,并且網(wǎng)頁人員,美工能獨自參與這些Web頁面的開發(fā)和維護(hù)。
在ASP.NET下,視圖的實現(xiàn)很簡單。可以像開發(fā)WINDOWS界面一樣直接在集成開發(fā)環(huán)境下通過拖動控件來完成頁面開發(fā)本。本文中介紹每一個頁面都采用復(fù)合視圖的形式即:一個頁面由多個子視圖(用戶部件)組成;子視圖可以是最簡單HTML 控件、服務(wù)器控件或多個控件嵌套構(gòu)而成的Web自定義控件。頁面都由模板定義,模板定義了頁面的布局,用戶部件的標(biāo)簽和數(shù)目,用戶指定一個模板,平臺根據(jù)這些信息自動創(chuàng)建頁面。針對靜態(tài)的模板內(nèi)容,如頁面上的站點導(dǎo)航,菜單,友好鏈接,這些使用缺省的模板內(nèi)容配置;針對動態(tài)的模板內(nèi)容(主要是業(yè)務(wù)內(nèi)容),由于用戶的請求不同,只能使用后期綁定,并且針對用戶的不同,用戶部件的顯示內(nèi)容進(jìn)行過濾。使用由用戶部件根據(jù)模板配置組成的組合頁面,它增強了可重用性,并原型化了站點的布局。
視圖部分大致處理流程如下:首先,頁面模板定義了頁面的布局;頁面配置文件定義視圖標(biāo)簽的具體內(nèi)容(用戶部件);然后,由頁面布局策略類初始化并加載頁面;每個用戶部件根據(jù)它自己的配置進(jìn)行初始化,加載校驗器并設(shè)置參數(shù),以及事件的委托等;用戶提交后,通過了表示層的校驗,用戶部件把數(shù)據(jù)自動提交給業(yè)務(wù)實體即模型。
這一部分主要定義了WEB頁面基類PageBase;頁面布局策略類PageLayout,完成頁面布局,用于加載用戶部件到頁面;用戶部件基類UserControlBase即用戶部件框架,用于動態(tài)加載檢驗部件,以及實現(xiàn)用戶部件的個性化。為了實現(xiàn)WEB應(yīng)用的靈活性,視圖部分也用到了許多配置文件例如:置文件有模板配置、頁面配置、路徑配置、驗證配置等。
2.2 控制器
為了能夠控制和協(xié)調(diào)每個用戶跨越多個請求的處理,控制機制應(yīng)該以集中的方式進(jìn)行管理。因此,為了達(dá)到集中管理的目的引入了控制器。應(yīng)用程序的控制器集中從客戶端接收請求(典型情況下是一個運行瀏覽器的用戶),決定執(zhí)行什么商業(yè)邏輯功能,然后將產(chǎn)生下一步用戶界面的責(zé)任委派給一個適當(dāng)?shù)囊晥D組件。
用控制器提供一個控制和處理請求的集中入口點,它負(fù)責(zé)接收、截取并處理用戶請求;并將請求委托給分發(fā)者類,根據(jù)當(dāng)前狀態(tài)和業(yè)務(wù)操作的結(jié)果決定向客戶呈現(xiàn)的視圖。在這一部分主要定義了HttpReqDispatcher(分發(fā)者類)、HttpCapture(請求捕獲者類)、Controller(控制器類)等,它們相互配合來完成控制器的功能。請求捕獲者類捕獲HTTP請求并轉(zhuǎn)發(fā)給控制器類。控制器類是系統(tǒng)中處理所有請求的最初入口點。控制器完成一些必要的處理后把請求委托給分發(fā)者類;分發(fā)者類分發(fā)者負(fù)責(zé)視圖的管理和導(dǎo)航,它管理將選擇哪個視圖提供給用戶,并提供給分發(fā)資源控制。在這一部分分別采用了分發(fā)者、策略、工廠方法、適配器等設(shè)計模式。
為了使請求捕獲者類自動捕獲用戶請求并進(jìn)行處理,ASP.NET 提供低級別的請求/響應(yīng) API,使開發(fā)人員能夠使用 .NET 框架類為傳入的 HTTP 請求提供服務(wù)。為此,必須創(chuàng)作支持 System.Web.IHTTPHandler 接口和實現(xiàn) ProcessRequest() 方法的類即:請求捕獲者類,并在web.config 的 <httphandlers> 節(jié)中添加類。ASP.NET 收到的每個傳入 HTTP 請求最終由實現(xiàn) IHTTPHandler 的類的特定實例來處理。IHttpHandlerFactory 提供了處理 IHttpHandler 實例 URL 請求的實際解析的結(jié)構(gòu)。HTTP 處理程序和工廠在 ASP.NET 配置中聲明為 web.config 文件的一部分。ASP.NET 定義了一個 <httphandlers> 配置節(jié),在其中可以添加和移除處理程序和工廠。子目錄繼承 HttpHandlerFactory 和 HttpHandler 的設(shè)置。 HTTP 處理程序和工廠是 ASP.NET 頁框架的主體。工廠將每個請求分配給一個處理程序,后者處理該請求。 例如,在全局 machine.config 文件中,ASP.NET 將所有對 ASPx 文件的請求映射到 HttpCapture類:
<httphandlers>
...
...
</httphandlers>
2.3 模型
MVC系統(tǒng)中的模型從概念上可以分為兩類――系統(tǒng)的內(nèi)部狀態(tài)和改變系統(tǒng)狀態(tài)的動作。模型是你所有的商業(yè)邏輯代碼片段所在。本文為模型提供了業(yè)務(wù)實體對象和業(yè)務(wù)處理對象:所有的業(yè)務(wù)處理對象都是從ProcessBase類派生的子類。業(yè)務(wù)處理對象封裝了具體的處理邏輯,調(diào)用業(yè)務(wù)邏輯模型,并且把響應(yīng)提交到合適的視圖組件以產(chǎn)生響應(yīng)。業(yè)務(wù)實體對象可以通過定義屬性描述客戶端表單數(shù)據(jù)。所有業(yè)務(wù)實體對象都EntityBase派生子類對象,業(yè)務(wù)處理對象可以直接對它進(jìn)行讀寫,而不再需要和request、response對象進(jìn)行數(shù)據(jù)交互。通過業(yè)務(wù)實體對象實現(xiàn)了對視圖和模型之間交互的支持。實現(xiàn)時把"做什么"(業(yè)務(wù)處理)和"如何做"(業(yè)務(wù)實體)分離。這樣可以實現(xiàn)業(yè)務(wù)邏輯的重用。由于各個應(yīng)用的具體業(yè)務(wù)是不同的,這里不再列舉其具體代碼實例。
三、MVC設(shè)計模式的擴(kuò)展
通過在ASP.NET中的MVC模式編寫的,具有極其良好的可擴(kuò)展性。它可以輕松實現(xiàn)以下功能:
①實現(xiàn)一個模型的多個視圖;
②采用多個控制器;
③當(dāng)模型改變時,所有視圖將自動刷新;
④所有的控制器將相互獨立工作。
這就是MVC模式的好處,只需在以前的程序上稍作修改或增加新的類,即可輕松增加許多程序功能。以前開發(fā)的許多類可以重用,而程序結(jié)構(gòu)根本不再需要改變,各類之間相互獨立,便于團(tuán)體開發(fā),提高開發(fā)效率。下面討論如何實現(xiàn)一個模型、兩個視圖和一個控制器的程序。其中模型類及視圖類根本不需要改變,與前面的完全一樣,這就是面向?qū)ο缶幊痰暮锰帯τ诳刂破髦械念悾恍枰黾恿硪粋€視圖,并與模型發(fā)生關(guān)聯(lián)即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。
同樣也可以實現(xiàn)其它形式的MVC例如:一個模型、兩個視圖和兩個控制器。從上面可以看出,通過MVC模式實現(xiàn)的應(yīng)用程序具有極其良好的可擴(kuò)展性,是ASP.NET面向?qū)ο缶幊痰奈磥矸较颉?/p>
四、MVC的優(yōu)點
大部分用過程語言比如ASP、PHP開發(fā)出來的Web應(yīng)用,初始的開發(fā)模板就是混合層的數(shù)據(jù)編程。例如,直接向數(shù)據(jù)庫發(fā)送請求并用HTML顯示,開發(fā)速度往往比較快,但由于數(shù)據(jù)頁面的分離不是很直接,因而很難體現(xiàn)出業(yè)務(wù)模型的樣子或者模型的重用性。產(chǎn)品設(shè)計彈性力度很小,很難滿足用戶的變化性需求。MVC要求對應(yīng)用分層,雖然要花費額外的工作,但產(chǎn)品的結(jié)構(gòu)清晰,產(chǎn)品的應(yīng)用通過模型可以得到更好地體現(xiàn)。
首先,最重要的是應(yīng)該有多個視圖對應(yīng)一個模型的能力。在目前用戶需求的快速變化下,可能有多種方式訪問應(yīng)用的要求。例如,訂單模型可能有本系統(tǒng)的訂單,也有網(wǎng)上訂單,或者其他系統(tǒng)的訂單,但對于訂單的處理都是一樣,也就是說訂單的處理是一致的。按MVC設(shè)計模式,一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復(fù)制,即減少了代碼的維護(hù)量,一旦模型發(fā)生改變,也易于維護(hù)。 其次,由于模型返回的數(shù)據(jù)不帶任何顯示格式,因而這些模型也可直接應(yīng)用于接口的使用。
再次,由于一個應(yīng)用被分離為三層,因此有時改變其中的一層就能滿足應(yīng)用的改變。一個應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需改動MVC的模型層。
控制層的概念也很有效,由于它把不同的模型和不同的視圖組合在一起完成不同的請求,因此,控制層可以說是包含了用戶請求權(quán)限的概念。
最后,它還有利于軟件工程化管理。由于不同的層各司其職,每一層不同的應(yīng)用具有某些相同的特征,有利于通過工程化、工具化產(chǎn)生管理程序代碼。
五、MVC的不足
MVC的不足體現(xiàn)在以下幾個方面:
(1)增加了系統(tǒng)結(jié)構(gòu)和實現(xiàn)的復(fù)雜性。對于簡單的界面,嚴(yán)格遵循MVC,使模型、視圖與控制器分離,會增加結(jié)構(gòu)的復(fù)雜性,并可能產(chǎn)生過多的更新操作,降低運行效率。
(2)視圖與控制器間的過于緊密的連接。視圖與控制器是相互分離,但確實聯(lián)系緊密的部件,視圖沒有控制器的存在,其應(yīng)用是很有限的,反之亦然,這樣就妨礙了他們的獨立重用。
(3)視圖對模型數(shù)據(jù)的低效率訪問。依據(jù)模型操作接口的不同,視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問,也將損害操作性能。
(4) 目前,一般高級的界面工具或構(gòu)造器不支持MVC模式。改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價是很高的,從而造成使用MVC的困難。
一:學(xué)會如何讀一個JavaWeb項目源代碼 步驟:表結(jié)構(gòu)-web.xml-mvc-db-spring
ioc-log- 代碼
1、先了解項目數(shù)據(jù)庫的表結(jié)構(gòu),這個方面是最容易忘記 的,有時候我們只顧著看每一個方法是怎么進(jìn)行的,卻沒
有去了解數(shù)據(jù)庫之間的主外鍵關(guān)聯(lián)。其實如果先了解數(shù)據(jù) 庫表結(jié)構(gòu),再去看一個方法的實現(xiàn)會更加容易。
2、然后需要過一遍web.xml,知道項目中用到了什么攔
截器,監(jiān)聽器,過濾器,擁有哪些配置文件。如果是攔截 器,一般負(fù)責(zé)過濾請求,進(jìn)行AOP 等;如果是監(jiān) 可能是定時任務(wù),初始化任務(wù);配置文件有如使用了 spring
后的讀取mvc 相關(guān),db 相關(guān),service 相關(guān),aop 相關(guān)的文件。
3、查看攔截器,監(jiān)聽器代碼,知道攔截了什么請求,這
個類完成了怎樣的工作。有的人就是因為缺少了這一步, 自己寫了一個action,配置文件也沒有寫錯,但是卻怎么
調(diào)試也無法進(jìn)入這個action,直到別人告訴他,請求被攔
4、接下來,看配置文件,首先一定是mvc相關(guān)的,如 springmvc
中,要請求哪些請求是靜態(tài)資源,使用了哪些 view 策略,controller 注解放在哪個包下等。 然后是db 相關(guān)配置文件,看使用了什么數(shù)據(jù)庫,使用了
什么orm框架,是否開啟了二級緩存,使用哪種產(chǎn)品作 為二級緩存,事務(wù)管理的處理,需要掃描的實體類放在什 么位置。最后是spring 核心的ioc
功能相關(guān)的配置文件, 知道接口與具體類的注入大致是怎樣的。當(dāng)然還有一些如 apectj 置文件,也是在這個步驟中完成
5、log
相關(guān)文件,日志的各個級別是如何處理的,在哪些 地方使用了log 記錄日志
6、從上面幾點后知道了整個開源項目的整體框架,閱讀 每個方法就不再那么難了。
7、當(dāng)然如果有項目配套的開發(fā)文檔也是要閱讀的。
差不多吧,根據(jù)公司不同,分的層數(shù)也不同,但是MVC三個主層視圖層,控制層,模型層肯定是沒錯的。再細(xì)分比如視圖層可以包含JSP,F(xiàn)ORM表單Bean等等。控制層里可以是Servlet,action,主要是接收視圖層的數(shù)據(jù),調(diào)用模型層方法的。模型層可以包含業(yè)務(wù)層,接收控制層傳來的數(shù)據(jù),調(diào)用持久化層。持久化層就是普通類不屬于MVC三層之中,主要寫關(guān)于數(shù)據(jù)庫的語句,由于它是對數(shù)據(jù)庫操作使用的,所以需要寫。其他的,比如DTO層,就是用來封裝數(shù)據(jù)的。MVC之間傳值用的,不屬于MVC。FORM表單Bean,是用來驗證表單信息的,跟JS差不多,但是JS是在客戶端驗證表單信息,不安全,表單Bean是在服務(wù)器端,能安全一些。等等。
MVC本來是存在于Desktop程序中的,M是指數(shù)據(jù)模型,V是指用戶界面,C則是控制器。使用MVC的目的是將M和V的實現(xiàn)代碼分離,從而使同一個程序可以使用不同的表現(xiàn)形式。比如一批統(tǒng)計數(shù)據(jù)你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步,一旦M改變,V應(yīng)該同步更新。
模型-視圖-控制器(MVC)是Xerox PARC在八十年代為編程語言Smalltalk-80發(fā)明的一種軟件設(shè)計模式,至今已被廣泛使用。最近幾年被推薦為Sun公司J2EE平臺的設(shè)計模式,并且受到越來越多的使用 ColdFusion 和 PHP 的開發(fā)者的歡迎。模型-視圖-控制器模式是一個有用的工具箱,它有很多好處,但也有一些缺點。
MVC如何工作
MVC是一個設(shè)計模式,它強制性的使應(yīng)用程序的輸入、處理和輸出分開。使用MVC應(yīng)用程序被分成三個核心部件:模型、視圖、控制器。它們各自處理自己的任務(wù)。
視圖
視圖是用戶看到并與之交互的界面。對老式的Web應(yīng)用程序來說,視圖就是由HTML元素組成的界面,在新式的Web應(yīng)用程序中,HTML依舊在視圖中扮演著重要的角色,但一些新的技術(shù)已層出不窮,它們包括Macromedia Flash和象XHTML,XML/XSL,WML等一些標(biāo)識語言和Web services.
如何處理應(yīng)用程序的界面變得越來越有挑戰(zhàn)性。MVC一個大的好處是它能為你的應(yīng)用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發(fā)生,不管這些數(shù)據(jù)是聯(lián)機存儲的還是一個雇員列表,作為視圖來講,它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。
模型
模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個部件中,模型擁有最多的處理任務(wù)。例如它可能用象EJBs和ColdFusion Components這樣的構(gòu)件對象來處理數(shù)據(jù)庫。被模型返回的數(shù)據(jù)是中立的,就是說模型與數(shù)據(jù)格式無關(guān),這樣一個模型能為多個視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫一次就可以被多個視圖重用,所以減少了代碼的重復(fù)性。
控制器
控制器接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求。所以當(dāng)單擊Web頁面中的超鏈接和發(fā)送HTML表單時,控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調(diào)用哪個模型構(gòu)件去處理請求,然后用確定用哪個視圖來顯示模型處理返回的數(shù)據(jù)。
現(xiàn)在我們總結(jié)MVC的處理過程,首先控制器接收用戶的請求,并決定應(yīng)該調(diào)用哪個模型來進(jìn)行處理,然后模型用業(yè)務(wù)邏輯來處理用戶的請求并返回數(shù)據(jù),最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù),并通過表示層呈現(xiàn)給用戶。
為什么要使用 MVC
大部分Web應(yīng)用程序都是用像ASP,PHP,或者CFML這樣的過程化語言來創(chuàng)建的。它們將像數(shù)據(jù)庫查詢語句這樣的數(shù)據(jù)層代碼和像HTML這樣的表示層代碼混在一起。經(jīng)驗比較豐富的開發(fā)者會將數(shù)據(jù)從表示層分離開來,但這通常不是很容易做到的,它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構(gòu)造MVC應(yīng)用程序需要一些額外的工作,但是它給我們帶來的好處是無庸質(zhì)疑的。
首先,最重要的一點是多個視圖能共享一個模型,正如我所提及的,現(xiàn)在需要用越來越多的方式來訪問你的應(yīng)用程序。對此,其中一個解決之道是使用MVC,無論你的用戶想要Flash界面或是 WAP 界面;用一個模型就能處理它們。由于你已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開,所以你可以最大化的重用你的代碼了。
由于模型返回的數(shù)據(jù)沒有進(jìn)行格式化,所以同樣的構(gòu)件能被不同界面使用。例如,很多數(shù)據(jù)可能用HTML來表示,但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能,例如,基于會話的購物車和電子商務(wù)過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應(yīng)用程序所重用。
因為模型是自包含的,并且與控制器和視圖相分離,所以很容易改變你的應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。如果你想把你的數(shù)據(jù)庫從MySQL移植到Oracle,或者改變你的基于RDBMS數(shù)據(jù)源到LDAP,只需改變你的模型即可。一旦你正確的實現(xiàn)了模型,不管你的數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務(wù)器,視圖將會正確的顯示它們。由于運用MVC的應(yīng)用程序的三個部件是相互對立,改變其中一個不會影響其它兩個,所以依據(jù)這種設(shè)計思想你能構(gòu)造良好的松偶合的構(gòu)件。
對我來說,控制器的也提供了一個好處,就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求,這樣控制器可以為構(gòu)造應(yīng)用程序提供強有力的手段。給定一些可重用的模型和視圖,控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理,然后選擇視圖將處理結(jié)果顯示給用戶。
MVC的缺點
MVC的缺點是由于它沒有明確的定義,所以完全理解MVC并不是很容易。使用MVC需要精心的計劃,由于它的內(nèi)部原理比較復(fù)雜,所以需要花費一些時間去思考。
你將不得不花費相當(dāng)可觀的時間去考慮如何將MVC運用到你的應(yīng)用程序,同時由于模型和視圖要嚴(yán)格的分離,這樣也給調(diào)試應(yīng)用程序到來了一定的困難。每個構(gòu)件在使用之前都需要經(jīng)過徹底的測試。一旦你的構(gòu)件經(jīng)過了測試,你就可以毫無顧忌的重用它們了。
根據(jù)我個人經(jīng)驗,由于我們將一個應(yīng)用程序分成了三個部件,所以使用MVC同時也意味著你將要管理比以前更多的文件,這一點是顯而易見的。這樣好像我們的工作量增加了,但是請記住這比起它所能帶給我們的好處是不值一提。
MVC并不適合小型甚至中等規(guī)模的應(yīng)用程序,花費大量時間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會得不償失。
MVC是一條創(chuàng)建軟件的好途徑
MVC設(shè)計模式是一個很好創(chuàng)建軟件的途徑,它所提倡的一些原則,像內(nèi)容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構(gòu)件,你可能需要重新思考你的應(yīng)用程序,尤其是應(yīng)用程序的構(gòu)架方面。如果你肯接受MVC,并且有能力應(yīng)付它所帶來的額外的工作和復(fù)雜性,MVC將會使你的軟件在健壯性,代碼重用和結(jié)構(gòu)方面上一個新的臺階。
通篇都是語法錯誤,你有多少的JAVA知識,書上代碼肯定是有省略的。
網(wǎng)頁標(biāo)題:mvc模式j(luò)ava源代碼,java web mvc模式
當(dāng)前路徑:http://chinadenli.net/article22/hsggjc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供ChatGPT、移動網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站、網(wǎng)站策劃、App設(shè)計、虛擬主機
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)