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

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

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

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

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

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

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

　　攔截http請求

　　將請求轉換成要執行的具體業務邏輯的操作

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

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

　　將視圖返回給客戶端

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

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

什么樣的框架算是MVC呢?

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

　　Model，負責業務領域狀態的知識

　　View，負責業務領域的表示視圖

　　Controller，負責控制用戶輸入的流和狀態

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

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

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