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

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

下面我就來闡述一下對于Web form，MVC是否值得我們?nèi)W(xué)習(xí)。

1.View State

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

還有就是View State在web form時代大行其道，在每個頁面都會存在，甚至在復(fù)雜的頁面中他的大小甚至很大，在每次 頁面回發(fā)時都會傳遞View State狀態(tài)，我們不說服務(wù)器解析這些View State需要時間，就是每次頁面?zhèn)鬏敹家獋鬟f這些View State就會使帶寬增加，顯示網(wǎng)頁的時間變長。這在2.0時代，最起碼是我所不允許的。

2.Page Life Cycle 頁面生命周期

在Web form中存在著復(fù)雜的生命周期，我甚至清楚的記得在我學(xué)習(xí)Web form的時候，都是拿著筆在紙上畫著這些周期圖，在每個周期頁面會執(zhí)行什么動作。這就像我在學(xué)習(xí)c#連接數(shù)據(jù)庫的時候?qū)憇ql helper，讓我很頭疼。例如在Page_render()中不應(yīng)該訪問具體的控件，因?yàn)檫@時控件還沒有生成（有園友提出錯誤，我查閱了資料也認(rèn)為這是錯誤的，因?yàn)檫@時已經(jīng)把控件渲染要輸出，特此聲明。感謝園友提出錯誤，我會積極改正），如果要訪問請?jiān)赑age_load()中，我們每天都要和Page_Load()事件打交道，至少我很經(jīng)常。IsPostBack是經(jīng)常可以見到的方法。

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

3.False sense of concerns 失敗的關(guān)注點(diǎn)分離

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

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

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

當(dāng)然了，這不是你可以轉(zhuǎn)向MVC的原因，但是是原因之一，雖然這個原因可能會有點(diǎn)牽強(qiáng)。

5.Leaky abstraction 脆弱的抽象

Web form試圖隱藏所有的http狀態(tài)（http的無記憶性或者是無狀態(tài)性）。我們在拖入一個服務(wù)器控件的時候從來需要考慮他會在什么時候顯示？因?yàn)榉?wù)器控件已經(jīng)實(shí)現(xiàn)了這些，例如，IsPostBack 方法為什么可以用來判斷頁面是否回發(fā)，它的實(shí)現(xiàn)原理是什么？我們不會關(guān)心，我們只關(guān)心這個方法能夠完成什么，這就夠了？真的夠了嗎？

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

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

6.Low testability 極差的可測試性

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

但是在MVC中，這些問題都不再存在，因?yàn)槲覀兛梢允褂肗unit等可以進(jìn)行單元測試的工具，我們可以把測試精確到每一行代碼，我們可以實(shí)現(xiàn)測試的自動化，避免了手動點(diǎn)擊浪費(fèi)的大量時間。這是一件好事，不是嗎？

還有我個人認(rèn)為最重要的一個原因就是，你如果有web form的開發(fā)基礎(chǔ)，那么學(xué)習(xí)MVC可以說就是很簡單的事情，因?yàn)镸VC中沒有了服務(wù)器控件，有的只是html標(biāo)簽以及一些可以生成html標(biāo)簽的helper類。我個人感覺做美工的如果想轉(zhuǎn)開發(fā)，這倒是不錯的時機(jī)，因?yàn)閔tml對于美工來說筆程序員更熟悉。

在MVC中沒有View State，可以對html進(jìn)行完全的控制，可以不再使用原來的Url rewriter，而是采用MVC中自帶的Route（Url路由系統(tǒng)），良好的關(guān)注點(diǎn)分離框架（Model、View、Controller），每一層都是負(fù)責(zé)自己的任務(wù)。

在MVC中不是每一個地址都會對一個一個具體的頁面，你可以定義多個Action，返回同一個頁面。在MVC中因?yàn)橛辛藦?qiáng)大的路由系統(tǒng)，所以我們不會再見到www.cnblogs.com/default.aspx,這樣的地址了，而是取而代之的www.cnblogs.com/home/index ,這是一個巨大的突破。可以讓特定的頁面具有具體的含義。這是URl友好，你認(rèn)為呢？

我并不是說MVC會取代Web form，而是他們之間的對比性，當(dāng)然如果可以避免一些問題的存在，那么讓MVC和Web from共存在同一個項(xiàng)目中，或許是不一個不錯的選擇。但是前提還是需要你學(xué)習(xí)MVC，我個人認(rèn)為在未來幾年中，Web form和MVC會共存。

好了，說了這么多，我只是有一句話，就是如果你想在未來的Web開發(fā)中不落后，那么就在業(yè)余時間學(xué)習(xí)一下MVC吧。

如果你想你的網(wǎng)站具有更好的可維護(hù)性，那么采用MVC是你的明智之舉。

以上只是我的個人所言，請各位參考??！

每天進(jìn)步一點(diǎn)，一年就會進(jìn)步一大步，十年就可以成功，君子當(dāng)自強(qiáng)不息，君子當(dāng)好好學(xué)習(xí)，每天進(jìn)步。

更多信息請查看IT技術(shù)專欄