MVC模式與三層架構的區別

以前老是混淆MVC表現模式和三層架構模式,爲此記錄下。程序員

三層架構和MVC是有明顯區別的,MVC應該是展示模式(三個加起來之後纔是三層架構中的UI層) 三層架構(3-tier application) 一般意義上的三層架構就是將整個業務應用劃分爲:表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。區分層次的目的即爲了「高內聚,低耦合」的思想。 一、表現層(UI):通俗講就是展示給用戶的界面,即用戶在使用一個系統的時候他的所見所得。    二、業務邏輯層(BLL):針對具體問題的操做,也能夠說是對數據層的操做,對數據業務邏輯處理。    三、數據訪問層(DAL):該層所作事務直接操做數據庫,針對數據的增添、刪除、修改、更新、查找等。 
MVC是 Model-View-Controller,嚴格說這三個加起來之後纔是三層架構中的UI層,也就是說,MVC把三層架構中的UI層再度進行了分化,分紅了控制器、視圖、實體三個部分,控制器完成頁面邏輯,經過實體來與界面層完成通話;而C層直接與三層中的BLL進行對話。
mvc能夠是三層中的一個表現層框架,屬於表現層。三層和mvc能夠共存。 三層是基於業務邏輯來分的,而mvc是基於頁面來分的。 MVC主要用於表現層,3層主要用於體系架構,3層通常是表現層、中間層、數據層,其中表現層又能夠分紅M、V、C,(Model View Controller)模型-視圖-控制器 數據庫

曾把MVC模式和Web開發中的三層結構的概念混爲一談,直到今天才發現一直是個人理解錯誤。MVC模式是GUI界面開發的指導模式,基於表現層分離的思想把程序分爲三大部分:Model-View-Controller,呈三角形結構。Model是指數據以及應用程序邏輯,View是指 Model的視圖,也就是用戶界面。這二者都很好理解,關鍵點在於Controller的角色以及三者之間的關係。在MVC模式中,Controller和View同屬於表現層,一般成對出現。Controller被設計爲處理用戶交互的邏輯。一個一般的誤解是認爲Controller負責處理View和Model的交互,而實際上View和Model之間是能夠直接通訊的。因爲用戶的交互一般會涉及到Model的改變和View的更新,因此這些能夠認爲是Controller的反作用。
MVC是表現層的架構,MVC的Model其實是ViewModel,即供View進行展現的數據。 ViewModel不包含業務邏輯,也不包含數據讀取。 而在N層架構中,通常還會有一個Model層,用來與數據庫的表相對應,也就是所謂ORM中的O。這個Model多是POCO,也多是包含一些驗證邏輯的實體類,通常也不包含數據讀取。進行數據讀取的是數據訪問層。而做爲UI層的MVC通常不直接操做數據訪問層,中間會有一個業務邏輯層封裝業務邏輯、調用數據訪問層。UI層(Controller)經過業務邏輯層來獲得數據(Model),並進行封裝(ViewModel),而後選擇相應的View。
MVC原本是存在於Desktop程序中的,M是指數據模型,V是指用戶界面,C則是控制器。使用MVC的目的是將M和V的實現代碼分離,從而使同一個程序可使用不一樣的表現形式。好比一批統計數據你能夠分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步,一旦M改變,V應該同步更新。 MVC如何工做 MVC是一個設計模式,它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分紅三個核心部件:模型、視圖、控制器。它們各自處理本身的任務。 視圖V 視圖是用戶看到並與之交互的界面。對老式的Web應用程序來講,視圖就是由HTML元素組成的界面,在新式的Web應用程序中,HTML依舊在視圖中扮演着重要的角色,但一些新的技術已層出不窮,它們包括Macromedia Flash和象XHTML,XML/XSL,WML等一些標識語言和Web services. 如何處理應用程序的界面變得愈來愈有挑戰性。MVC一個大的好處是它能爲你的應用程序處理不少不一樣的視圖。在視圖中其實沒有真正的處理髮生,無論這些數據是聯機存儲的仍是一個僱員列表,做爲視圖來說,它只是做爲一種輸出數據並容許用戶操縱的方式。 模型M 模型表示企業數據和業務規則。在MVC的三個部件中,模型擁有最多的處理任務。被模型返回的數據是中立的,就是說模型與數據格式無關,這樣一個模型能爲多個視圖提供數據。因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用,因此減小了代碼的重複性。 控制器C 控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。因此當單擊Web頁面中的超連接和發送HTML表單時,控制器自己不輸出任何東西和作任何處理。它只是接收請求並決定調用哪一個模型構件去處理請求,而後再肯定用哪一個視圖來顯示返回的數據。
模型Model 模型是應用程序的主體部分。模型表示業務數據,或者業務邏輯. 實現具體的業務邏輯、狀態管理的功能。 視圖View 視圖是應用程序中用戶界面相關的部分,是用戶看到並與之交互的界面。 就是與用戶實現交互的頁面,一般實現數據的輸入和輸出功能。 控制器controller 控制器工做就是根據用戶的輸入,控制用戶界面數據顯示和更新model對象狀態。起到控制整個業務流程的做用,實現View層跟Model層的協同工做。
3層架構指:表現層(顯示層) 業務邏輯層 數據訪問層(持久化)若是你們非要「生搬硬套」把它和MVC扯上關係話那我就只能在這裏"強扭這個瓜"了即: V 3層架構中"表現層"aspx頁面對應MVC中View(繼承的類不同) C 三層架構中"表現層"的aspx.cs頁面(類)對應MVC中的Controller,理解這一點並不難,你們想想咱們之前寫過的 Redirect,固然它自己就是跳轉了一些連接頁面,而MVC中的Controller要作的更爽,它控制並顯示輸出了一個視圖。即然所起到的做用都是對業務流程和顯示信息的控制,只不過是實現手段不一樣而已。 M 3層架構中業務邏輯層和數據訪問層對應MVC中Model(一定View和Controller已找到「婆家」剩下Model只能是業務邏輯層和數據訪問層了)
爲何要使用 MVC 大部分Web應用程序都是用像ASP,PHP,或者CFML這樣的過程化(自PHP5.0版本後已全面支持面向對象模型)語言來建立的。它們將像數據庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一塊兒。經驗比較豐富的開發者會將數據從表示層分離開來,但這一般不是很容易作到的,它須要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。儘管構造MVC應用程序須要一些額外的工做,可是它給咱們帶來的好處是無庸質疑的。 首先,最重要的一點是多個視圖能共享一個模型,如今須要用愈來愈多的方式來訪問你的應用程序。對此,其中一個解決之道是使用MVC,不管你的用戶想要Flash界面或是 WAP 界面;用一個模型就能處理它們。因爲你已經將數據和業務規則從表示層分開,因此你能夠最大化的重用你的代碼了。 因爲模型返回的數據沒有進行格式化,因此一樣的構件能被不一樣界面使用。例如,不少數據可能用HTML來表示,可是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能,例如,基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。 由於模型是自包含的,而且與控制器和視圖相分離,因此很容易改變你的應用程序的數據層和業務規則。若是你想把你的數據庫從MySQL移植到Oracle,或者改變你的基於RDBMS數據源到LDAP,只需改變你的模型便可。一旦你正確的實現了模型,無論你的數據來自數據庫或是LDAP服務器,視圖將會正確的顯示它們。因爲運用MVC的應用程序的三個部件是相互獨立,改變其中一個不會影響其它兩個,因此依據這種設計思想你能構造良好的鬆耦合的構件。 對我來講,控制器也提供了一個好處,就是可使用控制器來聯接不一樣的模型和視圖去完成用戶的需求,這樣控制器能夠爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖,控制器能夠根據用戶的需求選擇模型進行處理,而後選擇視圖將處理結果顯示給用戶。
拿一個簡單的登錄模塊說,需求是你輸入一個用戶名、密碼,若是輸入的跟預先定義好的同樣,那麼就進入到正確頁面,若是不同,就提示個錯誤信息「你Y別在這兒蒙我,輸入的不對!」。 V 這個小小的模塊中,起始的輸入用戶名密碼的頁面跟通過校驗後顯示的頁面就至關於View C 而這裏還須要一個controller頁面,就是用於接收輸入進來的用戶名密碼,還有通過校驗後返回的一個flg(此flg就是用於判斷你輸入的是否正確,而跳轉到相應的頁面的) M 最後還缺一個Model,那麼就是你那個用於校驗的類了,他就是處理你輸入的是否跟預先訂好的同樣不同的,以後返回一個flg。 這樣就徹底實現了邏輯跟頁面的分離,我頁面無論你咋整,反正我就一個顯示,而controller呢也無論你Model咋判斷對不對,反正我給你了用戶名跟密碼,你就得給我整回來一個flg來,而Medol呢,則是反正你敢給我個用戶名跟密碼,我就給你整過去個flg
m 提供數據,數據之間的關係,轉化等。並能夠通知視圖和控制器本身哪些地方發生了變化。 v 提供顯示,能根據m的改變來更新本身 c 好比視圖作了點擊一個按鈕,會先發給這個視圖的控制器,而後這個控制器來決定作什麼操做(讓模型更新數據,控制視圖改變) mvc是一個複合模式 mv,mc都是觀察者模式 m內部的組件組合模式 vc之間是策略模式(能夠隨時更換不一樣的控制器)設計模式

MVC模式是上世紀70年代提出,最初用於Smalltalk平臺上的。 MVC是表現模式,是用來向用戶展示的許多組建的一個模式(UI/Presentation Patten) MVC有三種角色: Model:用來儲存數據的組件(與領域模型概念不一樣,二者會相互交叉) View:從Model中獲取數據進行內容展現的組件。一樣的Model在不一樣的View下可展現不一樣的效果。獲取Model的狀態,而不對其進行操做。 Controller:接受並處理用戶指令(操做Model(業務)),選擇一個View進行操做。服務器

MVC概述:協做 存在單向引用,例如Model不知道View和Controller的存在。View不知道Controller的存在。這就隔離了表現和數據。View和controller是單向引用。而實際中View和Controller也是有數據交互的。架構

MVC的重要特色是分離。兩種分離: View和數據(Model)的分離 使用不一樣的View對相同的數據進行展現;分離可視和不可視的組件,可以對Model進行獨立測試。由於分離了可視組件減小了外部依賴利於測試。(數據庫也是一種外部組件) View和表現邏輯(Controller)的分離 Controller是一個表現邏輯的組件,並不是一個業務邏輯組件。MVC能夠做爲表現模式也能夠做爲建構模式,意味這Controller也能夠是業務邏輯。分離邏輯和具體展現,可以對邏輯進行獨立測試。mvc

MVC和三層架構 MVC與三層架構相似麼? View-UI Layer  |   Controller-Bussiness Layer  |  Model-Data Access Layer 其實這樣是錯誤的 MVC是表現模式(Presentation Pattern) 三層架構是典型的架構模式(Architecture Pattern) 三層架構的分層模式是典型的上下關係,上層依賴於下層。但MVC做爲表現模式是不存在上下關係的,而是相互協做關係。即便將MVC看成架構模式,也不是分層模式。MVC和三層架構基本沒有可比性,是應用於不一樣領域的技術。app

MVC模式與三層架構:框架

ui (view)←(contorller)測試

***********************網站

bll  (model)

***********************

dal (model)

 

 

又看到有人在問三層架構和MVC的關係,感受這種問題有點教條化了。由於它們都在邏輯上將應用程序劃爲三塊,湊了一個數字3,就有人非要把它們聯繫到一塊兒了。

  這兩個東西我接觸有幾年了,有一點體會,表達一下:

  三層是三層,MVC是MVC,它們毫無關係的。

三層是從整個應用程序架構的角度來分的三層(若是程序須要,還能夠分多層)。

  三層是爲了解決整個應用程序中各個業務操做過程當中不一樣階段的代碼封裝的問題,爲了使程序員更加專一的處理某階段的業務邏輯。

  好比將數據庫操做代碼封裝到一層中,提供一些方法根據參數直接返回用戶須要的相應數據,這樣在處理具體的業務邏輯的時候,就不用關心數據的存儲問題了。

MVC是在應用程序(BS結構)的視圖層劃分出來的不一樣功能的幾個模塊。

  MVC主要是爲了解決應用程序用戶界面的樣式替換問題,把展現數據的 HTML 頁面儘量的和業務代碼分離。MVC把純淨的界面展現邏輯(用戶界面)獨立到一些文件中(Views),把一些和用戶交互的程序邏輯(Controller)單獨放在一些文件中,在 Views 和 Controller 中傳遞數據使用一些專門封裝數據的實體對象,這些對象,統稱爲Models。

  只因此說MVC和三層毫無關係,是由於它們兩者使用範圍不一樣:三層能夠應用於任何語言、任何技術的應用程序;而MVC只是爲了解決BS應用程序視圖層各部分的耦合關係。它們互不衝突,能夠同時存在,也可根據狀況使用其中一種。

相關文章
相關標籤/搜索