ASP.NET’s MVC is what a joke!

很早前還在毀人不倦的時候就在懷疑MVC模式了，因為一向對這種從CS結構裡生搬硬套來的模式心存不爽。
什麼是MVC模式不必贅述，相信很多TX都能隨口道來一大篇，但是我們仔細想想這種在CS模型下百試不爽的最佳實務在Web裡仍然是最佳的嗎？
熟悉Web的工作原理的人都知道，Web應用是標準的Request-Response的方式在運作，所有的請求都是在瀏覽器發出，伺服器相應瀏覽器的請求，運算，得出結果，產生結果的頁面，返回給瀏覽器。但是，絕對不可能的是在瀏覽器沒有發起任何請求的情況下，伺服器就把頁面送過去了（過去有push技術，但是現在很長時間沒人提起了）。而MVC模式的在這樣子的工作環境下就不能採用推的技術，而必須在頁面有所請求的時候才能知道視圖的模型改變了，然後重繪視圖，而根本不是當模型改變的時候能夠主動地通知所有的視圖，所以如果強用MVC模型來設計的話就成了：

視圖發出請求給控制器-〉控制其根據請求操作資料->控制器擷取資料填充模型->控制器選擇視圖用模型填充之->顯示視圖

這樣子的過程和MVC模式的最佳實務的差距就不用多說了
我們來看看經典MVC的過程

Event(事件)導致Controller改變Model或View，或者同時改變兩者。只要Controller改變了Models的資料或者屬性，所有依賴的View都會自動更新。類似的，只要Controller改變了View，View會從潛在的Model中擷取資料來重新整理自己。

這裡我們可以看到區別：經典的MVC是用事件來自動驅動的，而Web的運作是過程化的，線性化的，所以我在使用MVC的時候才會感到無比的彆扭。
很多時候MVC的一些其它好處，比如可以將邏輯和介面分離（Struts的確做到了而且還不錯），所以很多人對這種生搬硬套的做法視而不見，所以個人以為，MVC並不是Web下的最佳實務，我們還能找到更好的方式，可能有的Framework已經在嘗試有所改變，不過名字還是沒改，還是叫MVC
----------------------------------------------------------------------
下面來說ASP.NET，ASP.NET實現了事件驅動的Web編程模型，本來是一個在Web上實現MVC的很好的契機，不過微軟在設計的時候有不少的缺憾，並沒有提出清晰的定義，2.0的時候有個MVP的提法，不過也沒有在設計上就定義得很明確（微軟的特點就是現有產品後有理論）。一般來說都把ASPX頁面當作視圖，頁面的.CS檔案作為控制器，視圖要麼類似javabean的類要麼就是DataSet（其實DataSet是好東西，我最喜歡的就是它）。其實這裡我覺得用UserControl作為視圖更加的合理一些（我一般都是這麼做的）。這裡通過事件來把這些串起來。不過在事件的設定上我認為微軟至少有幾點是沒有設定妥當的，一個是button事件的發生在PageLoad之後，按照邏輯來說，Button在點擊後應該觸發Button事件的代碼來處理資料的工作來改變模型，之後所有的視圖才可能擷取更新後的模型去重新整理介面，這裡把Load事件放在Button事件之前在邏輯上是說不通的，當然可以認為PageLoad是用來在頁面初始化的時候做一些處理，但是既然頁面已經保持了狀態為什麼在點擊按鈕後還是會重新Load呢？起碼之前和學生解釋這個問題的時候會話大半天的工夫耐心的講解Web的起源什麼的，如果既然要標榜事件化的頁面編程，就做徹底一點，把底層全部屏蔽，這裡留下一個trigger讓我們來踩地雷說明設計上在一開始就沒有想清楚，我看要麼就把pageload的功能更加單一化，只在頁面第一次開啟的時候執行，在有Postback的時候就不觸發了，免得還要自己用個if去做個複雜的結構，很多時候在PageLoad裡面要寫個很複雜的結構去區分各種情況，害得我都搞不清楚是在OO還是在寫意大利麵條。

不敢說精通MVC，只是對自己的理解提出看法，歡迎精通MVC的大蝦來批判我。

起了個很駭人的tital其實是在發牢騷，最近在用Karrigell，發現裡面根本不用去關心什麼request的問題，所有post的東西都直接成了變數，直接就是方法的參數，還可以通過重載方法的形式來handle具有多種參數組合的情況，想必在ASP.NET下寫出來意大利麵條難免牢騷更多。不過追求完美的想法是沒錯的，希望在3.0的時候能看到更加完美的ASP.NET。