最近流行MVC，不是因為大家都在用，而是他已經(jīng)在.NET缺席N多年。本文題目是亂取的，吸引眼球而已。

　　MVC是一個非常有爭議性的話題，首先，什么算是MVC，沒有一個統(tǒng)一的說法，眾說紛紜，Java,php都在爭吵不休，就跟別說已開始就壓根沒打算MVC的ASP.NET。在大家被微軟用CodeBehind和CodeBeside忽悠過去N多年之后，當大家在對WebForm審美疲勞后，MVC就跟李宇春一般另類且充滿吸引力。最近的新聞是微軟也要在ASP.NET中推出MVC了。對于很多M飯來說是一個十分值的慶祝的事情。順帶著MonoRail也雞犬升天，關注的人越來越多。WebForm未死，MVC卻活過來了。

　　所以這就是我不得不來發(fā)表對MVC一下看法的原因。上帝說“你應該了解真相，真相使你自由”，什么是MVC的真相呢?我想從來源說起，話說N多年前，在一個叫SmartTalk的國度出現(xiàn)了一個叫MVC的家伙，后來流竄到了Java國，在Java國里呼風喚雨(Java的很多有界面的組件，比如swing都是采用MVC模式設計的)。

這個MVC是個什么樣的家伙?

　　首先，此人長了三只手。一只叫Model，它負責業(yè)務領域狀態(tài)的知識，一只叫View，負責業(yè)務領域的表示視圖，一只叫Controller，負責控制用戶輸入的流和狀態(tài)。當模型某一部分發(fā)生變化的時候，通常使用事件通知表單來通知視圖。但是這個家伙在Web上操作的時候遇到了麻煩。因為Web的瀏覽器是沒有狀態(tài)的，所以模型沒有辦法通知視圖發(fā)生變化，而必須通過用戶發(fā)出另一次請求才能知道模型的改變。(以上內容源自《jakarta struts編程》一書)

　　所以這個家伙就將我迷惑住了，如果用戶需要請求兩次，那整個過程入口在哪里?View還是Control?

　　在微軟忽悠的MVP中，其實ASPx文件和ASPx.cs都被混成了一個類，那么這個所謂的PageController和View(ASPx頁面)是耦合起來的。反過來看Java的MVC，在jsp2.0規(guī)范中，不允許直接請求jsp頁面而是需要通過Servlet來重定向，具體的效果先不說，起碼倒是把Controller和View分開了，而且也統(tǒng)一了入口，都是從控制器進入的，那么控制器的職責也就很清晰了：

　　攔截http請求

　　將請求轉換成要執(zhí)行的具體業(yè)務邏輯的操作

　　判斷調用業(yè)務操作還是委托給處理程序

　　幫組用戶選擇要顯示給客戶端的下一個視圖

　　將視圖返回給客戶端

　　如果按照ASP.NET的WebForm來實現(xiàn)的話，那么4，5兩步就很讓人迷惑了，因為Controller和視圖已經(jīng)牢牢的綁定在了一起，如何選擇，如果將請求轉發(fā)，那么應該也將請求轉發(fā)給了下一個控制器而不是視圖。

　　所以微軟用一個MVP來忽悠了之后，大家反而迷惑了。所以新人注意了，如果你開始學WebForm就千萬不要看MVC，否則也會被忽悠。至于微軟新出的MVC，沒用過，不做評論。這里我總結一下我的觀點：

什么樣的框架算是MVC呢?

　　首先，M、V、C三部分的功能應該符合：

　　Model，負責業(yè)務領域狀態(tài)的知識

　　View，負責業(yè)務領域的表示視圖

　　Controller，負責控制用戶輸入的流和狀態(tài)

　　由于Web下的限制，Controller應該作為整個請求的入口，由Controller來組織業(yè)務邏輯(判斷請求和業(yè)務邏輯的對應關系，最終的實現(xiàn)還是Model)，而模型的改變通知視圖的功能也就應該由Controller來轉達一次(沒辦法，Web的限制，由于Controller被作為了入口，那么模型通知視圖變化的事件也之只能由Controller來觸發(fā)，或者也可以是Controller通知視圖模型變化了，然后視圖到模型去取數(shù)據(jù))。

　　其實從上面的分析看來，起碼來說視圖應該能夠根據(jù)模型自己組織輸出的外觀而不必假手Controller，但是在ASP.NET中實際的操作看來，模型都是通過控制器在綁定數(shù)據(jù)。

　　之前很早就看過Henry Fan兄的Nclay，其中的MVC組件給出的例子還沒好生研究，所以在這里也期待Henry兄給出自己的寶貴意見。

NET技術：混亂的MVC，.NET非要MVC不可么？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。