可以說，在未來幾年中，web form的使用會逐漸減少，而取而代之的就是mvc?？赡苣悴粫馕业挠^點，那么我就試著闡述一下我的觀點，如果你還是不能接受，那么請你反駁我。

學習一個新語言或者是新架構是需要時間的，我們需要摒棄原來學習的很深入并且用的很熟練的架構來迎合新架構嘛？是的，如果讓我說，我的回答是否，但是我需要看清這個新架構究竟和原來的架構有哪些改進，是否真的需要我們投入大量的時間去學習？mvc 是一種架構模式，它帶來了全新的和asp時代同樣的開發體驗（注：我不是說這是倒退）。

下面我就來闡述一下對于web form，mvc是否值得我們去學習。

1.view state

相信大家對于這個視圖狀態都很熟悉，它是用來保存我們在頁面中輸入的數據狀態，以便我們可以在刷新頁面或者回發時使頁面回到我們原來的輸入數據時的狀態，這個效果很好的實現了我們的需求。但是同時，我們要問自己一下，是否我們就真的需要這些，需要頁面刷新時顯示原來的數據，這是否是有意義的？

還有就是view state在web form時代大行其道，在每個頁面都會存在，甚至在復雜的頁面中他的大小甚至很大，在每次 頁面回發時都會傳遞view state狀態，我們不說服務器解析這些view state需要時間，就是每次頁面傳輸都要傳遞這些view state就會使帶寬增加，顯示網頁的時間變長。這在2.0時代，最起碼是我所不允許的。

2.page life cycle 頁面生命周期

在web form中存在著復雜的生命周期，我甚至清楚的記得在我學習web form的時候，都是拿著筆在紙上畫著這些周期圖，在每個周期頁面會執行什么動作。這就像我在學習c#連接數據庫的時候寫sql helper，讓我很頭疼。例如在page_render()中不應該訪問具體的控件，因為這時控件還沒有生成（有園友提出錯誤，我查閱了資料也認為這是錯誤的，因為這時已經把控件渲染要輸出，特此聲明。感謝園友提出錯誤，我會積極改正），如果要訪問請在page_load()中，我們每天都要和page_load()事件打交道，至少我很經常。ispostback是經?？梢砸姷降姆椒?。

如果你覺得你可以完全掌握這些生命周期，那么至少你是一名大牛。如果你可以很隨意的就控制頁面的生命周期，并且控制控件的生成，那么我會很敬仰你。

3.false sense of concerns 失敗的關注點分離

現在我們做軟件，講究的都是可維護性、可重用性以及關注點分離。何為關注點分離，我的理解就是每層結構只負責他自己的事情，不屬于他的不能控制，也不要試圖控制。例如，我們在code behind中寫了訪問數據庫的代碼，調用了sql helper中的類，但是現在是數據庫服務器的服務沒有開啟，那么這次調用肯定會拋出異常。難道讓我們在code behind中處理這些異常，那么我們程序員會累死的，異常應該是sql helper中處理，而不是code behind。這應該就是所謂的關注點分離。還有就是關注點分離應該是每個類只負責他自己的工作，而不要在一個類sql helper中有著返回html的語句出現。

4.limited control over html 對于html的控制極差

我在頁面生命周期中說了，如果你可以隨意的更改生成的控件，那么我會崇拜你。如果說對于一個服務器端控件可以控制生成html的樣式，或者生成html的id、name，以便可以讓js使用，這是很困難的。當然在.net 4.0中添加了一個屬性，那就是clientidmode,如果把這個屬性值設置為static，就可以生成和定義的id一樣的html的id值。默認情況下這是不被啟用的，會生成復雜的、嵌套的id值。這對于我們在客戶端操作html標簽是很困難的。

當然了，這不是你可以轉向mvc的原因，但是是原因之一，雖然這個原因可能會有點牽強。

5.leaky abstraction 脆弱的抽象

web form試圖隱藏所有的http狀態（http的無記憶性或者是無狀態性）。我們在拖入一個服務器控件的時候從來需要考慮他會在什么時候顯示？因為服務器控件已經實現了這些，例如，ispostback 方法為什么可以用來判斷頁面是否回發，它的實現原理是什么？我們不會關心，我們只關心這個方法能夠完成什么，這就夠了？真的夠了嗎？

我認為沒有，只是會使用，我想任何一個只要認識英文的人都可以完成，但是會使用就夠了嗎？性能問題達到了嗎？會出現哪些問題？我們都不知道，我們只是用了一個黑盒子，但是里面是什么東西我們不知道？如果是陷阱我們也會毫不猶豫的跳進去？對嗎？

偶爾的熟悉一下源碼，對于提升我們自己的開發水平有幫助之外，我們也可以發現很多我們可以控制的問題，避免他們發生？所以，親愛的朋友們，不要僅僅限于使用，有時候大牛和小牛的根本區別就是小牛不知道為什么要這樣？而大牛指導如何更好的這樣。

6.low testability 極差的可測試性

我在以前開發web form的時候，采用服務器控件可以大大的提高開發速度。但是，我從來不知道如何去測試我開發的代碼是否運行正常。唯一的方式就是自己一個人沒事的時候點擊、點擊、再點擊。還有就是設置斷點，按住f11，不斷的點擊鍵盤，直到看到這些代碼都想吐的地步？

但是在mvc中，這些問題都不再存在，因為我們可以使用nunit等可以進行單元測試的工具，我們可以把測試精確到每一行代碼，我們可以實現測試的自動化，避免了手動點擊浪費的大量時間。這是一件好事，不是嗎？

還有我個人認為最重要的一個原因就是，你如果有web form的開發基礎，那么學習mvc可以說就是很簡單的事情，因為mvc中沒有了服務器控件，有的只是html標簽以及一些可以生成html標簽的helper類。我個人感覺做美工的如果想轉開發，這倒是不錯的時機，因為html對于美工來說筆程序員更熟悉。

在mvc中沒有view state，可以對html進行完全的控制，可以不再使用原來的url rewriter，而是采用mvc中自帶的route（url路由系統），良好的關注點分離框架（model、view、controller），每一層都是負責自己的任務。

在mvc中不是每一個地址都會對一個一個具體的頁面，你可以定義多個action，返回同一個頁面。在mvc中因為有了強大的路由系統，所以我們不會再見到www.cnblogs.com/default.aspx,這樣的地址了，而是取而代之的www.cnblogs.com/home/index ,這是一個巨大的突破?？梢宰屘囟ǖ捻撁婢哂芯唧w的含義。這是url友好，你認為呢？

我并不是說mvc會取代web form，而是他們之間的對比性，當然如果可以避免一些問題的存在，那么讓mvc和web from共存在同一個項目中，或許是不一個不錯的選擇。但是前提還是需要你學習mvc，我個人認為在未來幾年中，web form和mvc會共存。

好了，說了這么多，我只是有一句話，就是如果你想在未來的web開發中不落后，那么就在業余時間學習一下mvc吧。

如果你想你的網站具有更好的可維護性，那么采用mvc是你的明智之舉。

以上只是我的個人所言，請各位參考?。?/P>