閑話Web編程模型：WebForm、MVP還是MVC？

此文寫給所有還在迷茫中的初學者並歡迎高手進來討論。
    首先什麼是Web編程模型？在這裡我們定義Web編程模型為如何編寫代碼產生html返回給終端使用者的方法。它包括兩部分，一個是如何編寫Web應用程式的規範，另一個則是實現這一規範的Web編程架構，而ASP.NET就是用來實現WebForm模型的架構，當然ASP.NET的功能比較強大，留下了足夠的空間，足夠我們在此基礎之上實現另外的模型，比如MonoRails。換個比方，和ASP.NET比較類似的，Jsp，Servlet也是實現Web編程模型的基礎結構，Sun所定義的Jsp2.0規範定義了一個如何編寫Web應用程式的規範，當然你可能不喜歡這麼做，那麼你還可以使用Struts或者SpringMVC，不過換湯不換藥，之不過是換了一種做法而已。
    WebForm其實是一個很好的Idear。在我才接觸WebForm編程的時候，當時的感觸是原來Web下還能這麼寫程式。在WebForm模型下，我們將整個瀏覽器當成一個表單來進行編程，把頁面上的元素都作為控制項來操作，拖放式，基於事件，不再是麵條式的流程式控制制，一切都是那麼的美好。但是很快的，隨著使用WebForm開發的項目數量越來越多，就越來越感覺到其中的弊端，其實罪過不在WebForm，而是在於微軟，把這麼好的概念給糟蹋了。
    WebForm的原罪：
    其一：控制項管得太寬，濫用Html樣式：
        所有的控制項都通過Html樣式管理自己的外觀，結果就算增加了Css屬性，但是Vs在編輯控制項的時候隨便點一點就自作主張的給你加上了Html樣式，很多時候還會很噁心的給你加上<font>標記，結果美工做得好好的Html代碼在Vs裡很快就變得面目全非，很多對Html熟悉的程式員就直接在Html視圖編輯代碼，結果WebForm 的所見即所得 (WYSIWYG)和拖放的特性就又喪失了。這一點在很注重外觀輸出的網站項目中很突出，結果是本來能夠提高效率的特性反而降低了效率。就算是在企業內部系統，領導要看的也是外觀，所以這一點是我極其厭惡的，自從2003以來就這樣了，而多年來微軟依然故我，完全沒有改變。
    其二：事件驅動，卻不徹底，結果造成初學者理解困難，而代碼也很醜陋
        主要指的就是那個很不清晰的Page_Load事件，玩過WinForm下編程的都知道，表單確實有一個Load事件，但是微軟在處理Page_Load的時候有一個很重要缺點，既然費了老大的力，用ViewState，不惜犧牲效能也要在WebForm下保證頁面看起來是保持了狀態的，也就是說在離開這個頁面前，這個頁面是要保持狀態的，那麼在離開這個頁面之前，這個頁面就只能Load一次，但是在微軟的WebForm下卻每一次都要Load頁面，所以很多從Winform轉過來的程式員在這裡就迷惑了。在之前的很多同學的Post裡都對這一點表示過不滿。但是看起來6年過去，微軟仍然沒有打算改正這一點，卻去費力的推MVP還弄了個MVC什麼的。其實把這一點
改正了，我都願意給WebForm加分。
    其三：頁面的表現和事件的邏輯混淆在一個類中。
        其實也就是aspx頁面和aspx.cs檔案的關係問題，這一點微軟在推MVP的時候其實也就是在這一點上做出了改進。不過.cs檔案到底是處理表示邏輯還是處理什麼其實大多數人都是迷糊。而且據某人的Post裡說新加坡的某大牛宣稱.CS就是控制器，Ok，就這點來說都是很混亂了，既然混亂，說明這裡也是個問題。
    我們該怎麼辦？其實很簡單兩個字：涼拌。既然微軟已經這麼做了，而我們靠ASP.NET吃飯的，如果要使用WebForm模式來編程，那麼我們也只有認命，然後改變可以改變的，克服不可改變的。架構的限制並不是我們不能完成項目的介面，而其他很多因素都比這一點更能影響項目的完成。所以與其費力在這一點上批評微軟，不如在專案管理上多花點功夫來得要緊。
    MVP由於是在WebForm的基礎上改進出來的，我也使用很少，就留給有深入瞭解的大牛來解釋了，我在這裡只有一點粗略的瞭解，就是MVP大約用來改進aspx和.cs耦合的問題，也就是WebForm的一個改進版，不過沒有編輯器的支援，而且一二兩點問題也沒有克服。一個子：唉！
    最後是MVC，其實MVC比起WebForm來更加的古老，作為一個種設計模式來說，其實把MVC應用於Web編程來說確實是老師傅遇到了新問題。首先是Web環境是屬於一種瘦用戶端的環境，所以在展示層：Html的能力其實很弱，只有get，post等有限的幾種方法，而且只能夠使用拉的方式，也就是每一次資料的更新都是通過瀏覽器主動發出請求而開始的，而經典的MVC模型所要求的當模型發生變化的時候通知視圖重新整理介面其實就成了mission imposiable，那麼現在在Web上的MVC架構其實都是經典MVC的變種，或者有人稱之為InputController，不過將表示，控制，模型分離開的思想其實是沒有錯的。也可以說在Web下的MVC其實也就是另外一種思考的模式而已，既然思考的方式不同，那麼要在WebForm下混合MVC也就成了不可能的任務。很多人這麼做的目的，也不過是既不想放棄方便的WebForm，有想要在設計上有清晰的代碼模型。雖然個人並不看好，但是但願能有人成功吧。
    總的來說WebForm和MVC不過是一種選擇而已，既然選擇了其中一種，也就是說路只有一條，改變可以改變的，接受不能改變的。或許有人想也許路不止這兩條，而ASP.NET也留給了我們足夠的自由度去實現我們所認定的不同的Web編程方式。但是其實結果都是一樣，如果真的是百花齊放，結果可能和python下的Web架構一樣變得無從選擇。而至於MonoRails，嗯，個人來說不是很喜歡，由於在公司我並不負責具體項目的編程任務所以我也不大喜歡一些一攬子解決方案，什麼都要負責，但是卻存在了過大的學習負擔，MonoRails對我來說太重了，很多時候我們只是需要一把起子的時候卻遞給你了一把瑞士軍刀。
    最後，正如怪怪所說，WebForm和MVC的爭論其實大可不必，不是一路的何必強求，與其爭論如何選擇，不如多花點時間在專案管理上，說不定收到的效果然而更好。多最佳化最佳化項目的管理，早點下班休息，多點時間回家陪陪父母，多點時間學習新東西，這才是正道啊。
    By the way，在java裡也不是MVC一統天下。感興趣的可以去看看Apache下的 Tapestry項目，感覺很類似WebForm了的事件驅動了，不過實現上區別還是很大。而上次在談金蝶的Opramask的時候也是感覺有些類似WebForm的感覺。