本來是不想跳出來充大頭蒜的，但最近發現園子裡關於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 針對具體問題的操作，也可以說是...