首頁 考試吧論壇 Exam8視線 考試商城 網絡課程 模擬考試 考友錄 實用文檔 繽紛校園 英語學習 | ||
2010考研 | 自學考試 | 成人高考 | 專 升 本 | 法律碩士 | MBA/MPA | 中 科 院 | ||
四六級 | 商務英語 | 公共英語 | 職稱日語 | 職稱英語 | 博思 | 口譯筆譯 | GRE GMAT | 日語 | 托福 | ||
雅思 | 專四專八 | 新概念 | 自考英語 | 零起點英、法、德、日、韓語 | 在職申碩英語 | ||
在職攻碩英語 | 成人英語三級 | ||
等級考試 | 水平考試 | 微軟認證 | 思科認證 | Oracle認證 | Linux認證 | ||
公務員 | 報關員 | 報檢員 | 外銷員 | 司法考試 | 導游考試 | 教師資格 | 國際商務師 | 跟單員 | ||
單證員 | 物流師 | 價格鑒證師 | 銀行從業(yè)資格 | 證券從業(yè)資格 | 人力資源管理師 | 管理咨詢師 | ||
期貨從業(yè)資格 | 社會工作者 | ||
會計職稱 | 注會CPA | 經濟師 | 統(tǒng)計師 | 注冊稅務師 | 評估師 | 精算師 | 高會 | ACCA | 審計師 | ||
法律顧問 | 會計證 | ||
一級建造師 | 二級建造師 | 造價師 | 監(jiān)理師 | 安全師 | 咨詢師 | 結構師 | 建筑師 | 安全評價師 | ||
房地產估價師 | 土地估價師 | 設備監(jiān)理師 | 巖土工程師 | 質量資格 | 房地產經紀人 | 造價員 | ||
投資項目管理 | 土地代理人 | 環(huán)保師 | 環(huán)境影響評價 | 物業(yè)管理師 | 城市規(guī)劃師 | 公路監(jiān)理師 | ||
公路造價工程師 | 招標師 | ||
執(zhí)業(yè)護士 | 執(zhí)業(yè)醫(yī)師 | 執(zhí)業(yè)藥師 | 衛(wèi)生資格 |
MVC模式是一個復雜的架構模式,其實現(xiàn)也顯得非常復雜。但是,我們已經終結出了很多可靠的設計模式,多種設計模式結合在一起,使MVC模式的實現(xiàn)變得相對簡單易行。Views可以看作一棵樹,顯然可以用Composite Pattern來實現(xiàn)。Views和Models之間的關系可以用Observer Pattern體現(xiàn)。Controller控制Views的顯示,可以用Strategy Pattern實現(xiàn)。Model通常是一個調停者,可采用Mediator Pattern來實現(xiàn)。
現(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英文即Model-View-Controller,即把一個應用的輸入、處理、輸出流程按照Model、View、Controller的方式進行分離,這樣一個應用被分成三個層——模型層、視圖層、控制層。
視圖(View)代表用戶交互界面,對于Web應用來說,可以概括為HTML界面,但有可能為XHTML、XML和Applet。隨著應用的復雜性和規(guī)模性,界面的處理也變得具有挑戰(zhàn)性。一個應用可能有很多不同的視圖,MVC設計模式對于視圖的處理僅限于視圖上數(shù)據(jù)的采集和處理,以及用戶的請求,而不包括在視圖上的業(yè)務流程的處理。業(yè)務流程的處理交予模型(Model)處理。比如一個訂單的視圖只接受來自模型的數(shù)據(jù)并顯示給用戶,以及將用戶界面的輸入數(shù)據(jù)和請求傳遞給控制和模型。
模型(Model):就是業(yè)務流程/狀態(tài)的處理以及業(yè)務規(guī)則的制定。業(yè)務流程的處理過程對其它層來說是黑箱操作,模型接受視圖請求的數(shù)據(jù),并返回最終的處理結果。業(yè)務模型的設計可以說是MVC最主要的核心。目前流行的EJB模型就是一個典型的應用例子,它從應用技術實現(xiàn)的角度對模型做了進一步的劃分,以便充分利用現(xiàn)有的組件,但它不能作為應用設計模型的框架。它僅僅告訴你按這種模型設計就可以利用某些技術組件,從而減少了技術上的困難。對一個開發(fā)者來說,就可以專注于業(yè)務模型的設計。MVC設計模式告訴我們,把應用的模型按一定的規(guī)則抽取出來,抽取的層次很重要,這也是判斷開發(fā)人員是否優(yōu)秀的設計依據(jù)。抽象與具體不能隔得太遠,也不能太近。MVC并沒有提供模型的設計方法,而只告訴你應該組織管理這些模型,以便于模型的重構和提高重用性。我們可以用對象編程來做比喻,MVC定義了一個頂級類,告訴它的子類你只能做這些,但沒法限制你能做這些。這點對編程的開發(fā)人員非常重要。
業(yè)務模型還有一個很重要的模型那就是數(shù)據(jù)模型。數(shù)據(jù)模型主要指實體對象的數(shù)據(jù) 保存(持續(xù)化)。比如將一張訂單保存到數(shù)據(jù)庫,從數(shù)據(jù)庫獲取訂單。我們可以將這個模型單獨列出,所有有關數(shù)據(jù)庫的操作只限制在該模型中。
控制(Controller)可以理解為從用戶接收請求, 將模型與視圖匹配在一起,共同完成用戶的請求。劃分控制層的作用也很明顯,它清楚地告訴你,它就是一個分發(fā)器,選擇什么樣的模型,選擇什么樣的視圖,可以完成什么樣的用戶請求。控制層并不做任何的數(shù)據(jù)處理。例如,用戶點擊一個連接,控制層接受請求后, 并不處理業(yè)務信息,它只把用戶的信息傳遞給模型,告訴模型做什么,選擇符合要求的視圖返回給用戶。因此,一個模型可能對應多個視圖,一個視圖可能對應多個模型。
模型、視圖與控制器的分離,使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數(shù)據(jù),所有其它依賴于這些數(shù)據(jù)的視圖都應反映到這些變化。因此,無論何時發(fā)生了何種數(shù)據(jù)變化,控制器都會將變化通知所有的視圖,導致顯示的更新。這實際上是一種模型的變化-傳播機制。模型、視圖、控制器三者之間的關系和各自的主要功能,如圖1所示。