從三層架構到MVC,MVP

2021-09-22 03:43:20 字數 4557 閱讀 5405

本來是不想跳出來充大頭蒜的,但最近發現園子裡關於mvc的文章和討論之風越刮越烈,其中有些朋友的觀點並不是我所欣賞和推薦的,同時最近也在忙著給公司裡的同事做mvc方面的「掃盲工作」。所以就蒐集了一些大家接觸mvc的過程中經常出現的問題做了一下解釋說明,希望能與大家多多交流,呵呵。

當然這種架構模式本身的一些問題也會在接下來的內容就加以介紹,另外就是如果大家有什麼不同觀點的話,歡迎拍磚(只要不打臉就行,呵呵)。

一.  mvc是誰提出的

模型-檢視-控制器(mvc)是xerox parc在八十年代為程式語言smalltalk-80發明的一種軟體設計模式,至今已被廣泛使用。最近幾年被推薦為sun公司j2ee平台的設計模式,並且受到越來越多的使用 coldfusion 和 php 的開發者的歡迎。模型-檢視-控制器模式是乙個有用的工具箱,它有很多好處,但也有一些缺點。

二.  mvc是否適合進行大專案的開發

mvc框架肯定是適合於做大專案開發的,但並不是說有了mvc框架我們就可以開發大專案,聽起來有些繞,其實道理很簡單,原因就是人(開發者)。如果你是乙個對mvc框架的設計理念有深入研究的人,那麼你在使用mvc框架進行產品和專案開發的時候就會隨時隨地都要考慮一些問題:

1.低耦合性(強調檢視層和業務層分離)

2.可測試性(這個非常重要)

3.高重用性和可適用性

4.有利於軟體工程化管理等等。

這裡我很欣賞老趙的治學態度,因為在他的文章和**中隨時隨地都在進行著思考,特別是其對可測試性,單元測試(這裡不是什麼tdd)的思考,讓我看起來有心靈相通的感覺。因為這些問題都是在做中型甚至大型專案中要認真思考的,決不是說微軟給的例子就是我們的唯一準則,必定裡面有對也有錯,我相信在mvc面前,國內甚至微軟內部的牛人都不是很多。

說了這些,大家可以意識到了,如果在沒有理解下面這張圖以及對mvc的「所謂優點是從何處得到的」有認識,而一上來就去拿mvc去開發大型專案的話,我想不僅不能發揮asp.net mvc框架的估勢,相反會時時受制於裡面的約束,配置和功能特性,最後感覺還不如直接用asp.net webform開發來的直接,不是嗎?真要是到了這一境地,我想不僅無法使用mvc進行大型目開發,就連中小企業應用都應付不來。

三.  能不能使用mvc架構進行webform的開發

四. 傳統的三(n)層架構與mvc,以及mvc與mvp關係

本文所說的三層架構指:表現層(顯示層), 業務邏輯層, 資料訪問層(持久化)。如果大家非要「生搬硬套」的把它與mvc扯上關係的話,那我就只能在這裡"強扭這個瓜"了,即:

三層架構中"表現層"的aspx頁面對應mvc中的view(繼承的類不一樣)    

三層架構中"表現層"的aspx.cs頁面(類)對應mvc中的controller,理解這一點並不難,大家想一想我們以前寫過的redirect,當然它本身就是跳轉了一些鏈結頁面,而mvc中的controller要做的更爽,它控制並顯示輸出了乙個檢視。即然所起到的作用都是對業務流程和顯示資訊的控制,只不過是實現手段不同而已。

三層架構中業務邏輯層和資料訪問層對應mvc中的model(必定view和controller已找到「婆家」,剩下的model只能是業務業務層和資料訪問層的了,呵呵)。但其實微軟的一些mvc示例專案中對這個問題理解的並不是這樣簡單,這一點在我之前的

關於兩個mvc示例的思考(mvcstore和oxite)

已闡述過,就不多說了。  

其實明白了這個關係,就可以嘗試把以前的三層結構遷移到mvc框架下,當然在這個過程中肯定會遇到這樣或那樣的問題,但原則就是把將mvc的優勢發揮到極致,要不然還不如不做。

說到這裡,其實早在n年前就有人提出使用frontcontroller(前端控制器)來實現對http頁面請求的路由跳轉(包括資料的展現),說白了就是使用httphandler來進行頁面請求的處理和資料繫結,而不是完全「指望」普通的頁面訪問重定向等。這樣做的目的,就我而言與routing中的controller和action的出發點標是一致的,只不過routing實現的更優雅同時也更底層一些。

說完了三層架構,再看看mvc與mvp,其實在這之前我們有必要看一下這張圖:

看完了上面的圖,大家就會發現mvp與mvc最大的乙個區別就是「model與view層之間倒底該不該通訊(甚至雙向通訊,如圖)。我想這也是目前做這兩方面研究的專家所互相爭論的戰場。必定各有各的好處和因好處要付出的代價。起碼在mvp模式下的presenter要擁有「絕對權力」。如果沒有它,model與view就是兩個孤島,儘管各有各的地盤(完全解耦),但不會給企業帶來什麼有用的價值。

所以我這裡有乙個比喻來形容mvp中的:

presenter ----就是乙個控制欲極強的女人,甚至就連「用什麼姿勢」,它都要管一管。

當然日裡萬機操心多了就會讓自己要做的事越來越多,最終它面臨的就是該層**日益龐雜,且書寫起來不太方便,必定就連事件繫結這類雞毛算皮的事都要歸它管,累不累呀。最終我們看到mvp中的view就真的**輕閒了不少(國企職工嘛),難怪說view只要從相應的iview介面下實現相應的屬性和一些簡單方法就完事了,而最終呼叫iview介面下的那個檢視例項則完全交給了presenter,

這讓我想到了mvc中可以支援「自定義模版引擎(最終由mvc框架來控制使用系統還是自定義的模版引擎)」以及平時大家常掛在嘴邊的換膚功能,想到這裡多少還真有那麼點意思了(精神層面上)。

當然在微軟內部對mvp的理解也有所不同,如下圖中所說的supervising controller模式和上面大家看到的passiveview.

supervising controller模式其實很接近於mvc的那張圖了,只是又提供了presenter與view之間的「雙向通訊」。這種做法也是有很多不同意見的,起碼對那些支援「單向依賴」的開發者而言是「嗤之以鼻」的。

說到這裡,表達一下我的觀點,我是偏向於passiveview的,雖然這種模式有些霸道,但必定是讓model和view之間真正解耦,為開發者提供了最大的「控制成就感」,可以說想怎麼控制檢視就怎麼控制,但因此所造成的問題就是**書寫量和實現複雜性等問題了。

五.  controller和model中該有哪些東東

因為view中的邏輯比較簡單,所以對系統複雜性的考慮基本上要重點放在model中,而controller是對業務流程的控制,其應該保持「**清爽」。說是這麼說,但實際進行專案開發時這兩者之間的界線能這麼清楚嗎,答案是「盡量保(堅)持」。必定這是mvc的「特色」嘛。

另外這裡向大家推薦乙個不錯的方法"robustness",有了它您就可以很容易的找出那些系統方法要放在model中,哪些該歸入控制邏輯中了,該方法我在兩年前的一篇文章中提到過,大家感興趣的話可以看看這個鏈結, 採用[iconix] 方法實踐blog設計之四 [健壯性分析] .

其核心內容如下:   

實體物件(entity object):

通常是來自域模型中的物件(也就是現實世界),它常對應於資料庫表和檔案,這些資料表   和檔案中儲存了執行用例所需的資料。有些實體物件是「臨時」物件(如搜尋結果),當用例   結束後將消失。

邊界物件(boundary object):

參與者使用它來同系統互動,這通常包含視窗,螢幕,對話方塊和選單。如果有gui原型,   將會知道許多主要的邊界物件是什麼。

控制物件(control object):

將邊界物件和實體物件關聯起來(通常被稱為控制器,因為它們通常不是真正的物件),   它包含了大部分應用邏輯,它們在使用者和儲存的資料之間架起一座橋梁。控制物件中包含經常   修改的業務規則和策略。這樣修改只需要在這些物件中進行,而不會涉及到使用者介面和資料庫   模式。控制器偶爾 (20%的時間內)也會是設計中的「真正物件」,但大部分時間內,控制器只是乙個佔位符,用於避免您遺漏用例要求的任何功能和系統行為。

上面的三個物件分別對應model, view, controller.

正如文中所說,該方法還提供了如下好處:    

六.mvc與mvp是否可以同時出現在乙個sln甚至乙個專案中

這一點我想誰說了都不算數,只有使用者需求才是王道,使用者使用在當前專案中實現某些特定功能,而該功能恰恰是mvc或mvp的用武之地,那就乙個字:「」。

最後還要再說明一點:

業務邏輯是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計,所以說乙個系統來說,業務邏輯是無處不在的。view上的是顯示邏輯,controller上是流程控制邏輯),model上簡直就是「邏輯大本營」了。

使用 mvc 框架時我們要將「經常變化」的業務規則(位於controller)和相對穩定的業務邏輯(位於model)分離開,同時在model層採用介面方式實現,以此來應對將來不斷變化的業務需求。

好了,今天的內容就先到這裡了。

從三層架構到MVC MVP

當然這種架構模式本身的一些問題也會在接下來的內容就加以介紹,另外就是如果大家有什麼不同觀點的話,歡迎拍磚 只要不打臉就行,呵呵 一.mvc是誰提出的 模型 檢視 控制器 mvc 是xerox parc在八十年代為程式語言smalltalk 80發明的一種軟體設計模式,至今已被廣泛使用。最近幾年被推薦...

c mysql三層架構例項 三層架構例項

一 概要 這篇部落格,準備用乙個小demo來介紹應該實現三層架構。三層架構只是分層的一種經典形式,到底分幾層,要依具體情況而定,考慮到系統的複雜程度,和後期的可維護性,完全可以分四層,五層,甚至六層,七層。二 demo 1 實現語言 vb.net 2 需求 學校機房收費系統 中的乙個功能 操作員為學...

軟體架構 三層架構

三層系統的分層式結構 三層架構 3 tier architecture 通常意義上的三層架構就是將整個業務應用劃分為 區分層次的目的即為了 高內聚,低耦合 的思想。表現層 ui 通俗講就是展現給使用者的介面,即使用者在使用乙個系統的時候他的所見所得。業務邏輯層 bll 針對具體問題的操作,也可以說是...