對於微軟爲什麼要推出ASP.NET MVC，我們是無從得知的，也許是因爲JavaEE平臺上有Struts，也許是因爲MVC太流行，也許微軟是想使得自己的Web App平臺更完善，總之我們只能猜測。但是如果回顧一下微軟的Web App平臺進化過程，還是很有意思的。
ASP——微軟最早爲Web開發做出的貢獻可能就是ASP了，這個動態語言把動態網頁開發的難度空前降低了。但是，在很多人興奮的用ASP寫着一個又一個動態網頁時，它的缺點漸漸暴露：語言過於簡單，沒有面向對象支持、沒有好的IDE支持、動態腳本和靜態HTML雜糅在一起，使得修改及維護極爲困難。
Web Form——說實話，即使是用現在的眼光看，微軟推出的Web Form編程模型確實是很有創意，也很實用。微軟開創性地將桌面應用的開發模式引入Web應用開發：拖控件、寫事件處理、運行...一切都那麼美好，而且前段靜態代碼和後端程序完全隔離在兩個文件裏，並且用戶可以使用.NET平臺上任意一種語言進行後端編程。對程序員來說，使用C#進行編程比使用ASP實在是舒服太多了。所以，Web Form模型可以說成爲.NET Web App開發的代名詞，所有基於.NET平臺的Web開發人員都熟悉並接受了這種模型。
ASP.NET MVC——就在Web Form大行其道時，微軟推出了ASP.NET MVC。嚴格說，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一個完整的新型模型，從頂層到底層是一整套的東西，而ASP.NET MVC只是給Web Form穿了件MVC樣子的外套，它應該是基於Web Form的一種編程方式模型擴展。但是，從開發人員看，ASP.NET MVC的推出確實大大改變了我們的開發方式，很多Web Form下的方式不被提倡了（你仍可以用，因爲ASP.NET MVC也是基於Web Form的），例如，曾飽受讚揚的服務器端控件再度被拋棄，轉而再次使用客戶端控件，事件驅動模型被拋棄，轉而使用了類似傳統的Url跳轉處理模型。而且在數據驗證等方式上與Web Form下提倡的方式有了很大變化。
如此看來，真像是一個輪迴，似乎ASP.NET MVC又把我們帶回到了ASP時代：服務器端模型不讓用、事件驅動機制不讓用、類似Desktop App的開發方式不讓用...我們似乎從Web Form回到了傳統的ASP時代。但是，真的是這樣嗎？當然不是！
只要稍微用一下，就知道雖然ASP.NET MVC提倡我們廢除Web Form下的很多東西和習慣，但是絕不是讓我們“迴歸原始”，如果非要說是一個輪迴，那也應該說是一個螺旋式的輪迴，是上升式的輪迴。
記得馬克思主義哲學中有個很經典的命題：對於新事物來說，道路是曲折的，前途是光明的。也許，Web App模型的發展就印證了這個觀點吧。也許，服務器端控件、事件驅動模型這些東西一開始就是不適合Web App的，微軟走了很多彎路，現在找到了正確的方向。拋棄的痛苦的，我們要拋棄曾經認爲多麼習慣並且傾注了大量心血的東西，但是，事物被否定後，剩下的的一個蛻變出的新事物，是一個更優秀的東西。
例如，我們拋棄了用了多年的務器端控件、事件驅動模型……但是我們得到了低耦合的、關注被分離的、符合MVC模型的新的Web模型。要敢於否定，才能獲得新生。微軟是，我們也是。
ASP.NET MVC帶來的變化
下面，我們看看ASP.NET MVC到底讓我們否定什麼？又能得到什麼。
1.服務器端表單控件。
由於ASP.NET MVC的特質，服務器端的表單控件不再被提倡使用，例如我們的文本框，不再使用asp:TextBox，而是使用傳統的input，或直接讓Html.TextBox生成。總之，很多服務器端控件被我們廢止了。甚至GridView這樣曾給我們帶來無限快感的老朋友，也不再被提倡使用。但是，並不是說不能用任何服務器端控件，例如，爲了實現母版，我們的ContentPlaceHolder還是必須要使用的。
2.事件驅動模型。
既然服務器端表單控件已經不提倡使用了，事件驅動模型自然也不被提倡，兩者本來就是相輔相成的。在ASP.NET MVC中，當某個按鈕被點擊，你不要再習慣性想到應該在相應的aspx.cs中有個時間處理方法，你應該想到的是該有某個Controller中有個Action來處理這個事件。實際上，在ASP.NET MVC中，提倡不要在aspx.cs中寫任何邏輯代碼。甚至應該當他們不存在。
3.數據綁定
對於列表式表格數據，你一定習慣了GridView的數據綁定，可是，從你使用ASP.NET MVC開始，這不在被提倡了。你應該自己處理數據的顯示。當然，我們也可以期待未來的ASP.NET MVC正式版中會有一個強大的Helper來幫我們做數據顯示。
ASP.NET MVC的收益
你一定想知道，我們爲使用ASP.NET付出瞭如此慘烈的代價，那麼我們能得到什麼？從我個人認爲，你至少得到了以下東西：
1.清晰的、關注被分離的代碼；
2.更容易的測試及維護；
3.更符合MVC的表示層；
4.你可以向Java程序員自豪的說：我現在也用MVC模式了，而且不用寫任何XML！
ASP——微軟最早爲Web開發做出的貢獻可能就是ASP了，這個動態語言把動態網頁開發的難度空前降低了。但是，在很多人興奮的用ASP寫着一個又一個動態網頁時，它的缺點漸漸暴露：語言過於簡單，沒有面向對象支持、沒有好的IDE支持、動態腳本和靜態HTML雜糅在一起，使得修改及維護極爲困難。
Web Form——說實話，即使是用現在的眼光看，微軟推出的Web Form編程模型確實是很有創意，也很實用。微軟開創性地將桌面應用的開發模式引入Web應用開發：拖控件、寫事件處理、運行...一切都那麼美好，而且前段靜態代碼和後端程序完全隔離在兩個文件裏，並且用戶可以使用.NET平臺上任意一種語言進行後端編程。對程序員來說，使用C#進行編程比使用ASP實在是舒服太多了。所以，Web Form模型可以說成爲.NET Web App開發的代名詞，所有基於.NET平臺的Web開發人員都熟悉並接受了這種模型。
ASP.NET MVC——就在Web Form大行其道時，微軟推出了ASP.NET MVC。嚴格說，ASP.NET MVC和Web Form是不具有可比性的，Web Form是一個完整的新型模型，從頂層到底層是一整套的東西，而ASP.NET MVC只是給Web Form穿了件MVC樣子的外套，它應該是基於Web Form的一種編程方式模型擴展。但是，從開發人員看，ASP.NET MVC的推出確實大大改變了我們的開發方式，很多Web Form下的方式不被提倡了（你仍可以用，因爲ASP.NET MVC也是基於Web Form的），例如，曾飽受讚揚的服務器端控件再度被拋棄，轉而再次使用客戶端控件，事件驅動模型被拋棄，轉而使用了類似傳統的Url跳轉處理模型。而且在數據驗證等方式上與Web Form下提倡的方式有了很大變化。
如此看來，真像是一個輪迴，似乎ASP.NET MVC又把我們帶回到了ASP時代：服務器端模型不讓用、事件驅動機制不讓用、類似Desktop App的開發方式不讓用...我們似乎從Web Form回到了傳統的ASP時代。但是，真的是這樣嗎？當然不是！
只要稍微用一下，就知道雖然ASP.NET MVC提倡我們廢除Web Form下的很多東西和習慣，但是絕不是讓我們“迴歸原始”，如果非要說是一個輪迴，那也應該說是一個螺旋式的輪迴，是上升式的輪迴。
記得馬克思主義哲學中有個很經典的命題：對於新事物來說，道路是曲折的，前途是光明的。也許，Web App模型的發展就印證了這個觀點吧。也許，服務器端控件、事件驅動模型這些東西一開始就是不適合Web App的，微軟走了很多彎路，現在找到了正確的方向。拋棄的痛苦的，我們要拋棄曾經認爲多麼習慣並且傾注了大量心血的東西，但是，事物被否定後，剩下的的一個蛻變出的新事物，是一個更優秀的東西。
例如，我們拋棄了用了多年的務器端控件、事件驅動模型……但是我們得到了低耦合的、關注被分離的、符合MVC模型的新的Web模型。要敢於否定，才能獲得新生。微軟是，我們也是。
ASP.NET MVC帶來的變化
下面，我們看看ASP.NET MVC到底讓我們否定什麼？又能得到什麼。
1.服務器端表單控件。
由於ASP.NET MVC的特質，服務器端的表單控件不再被提倡使用，例如我們的文本框，不再使用asp:TextBox，而是使用傳統的input，或直接讓Html.TextBox生成。總之，很多服務器端控件被我們廢止了。甚至GridView這樣曾給我們帶來無限快感的老朋友，也不再被提倡使用。但是，並不是說不能用任何服務器端控件，例如，爲了實現母版，我們的ContentPlaceHolder還是必須要使用的。
2.事件驅動模型。
既然服務器端表單控件已經不提倡使用了，事件驅動模型自然也不被提倡，兩者本來就是相輔相成的。在ASP.NET MVC中，當某個按鈕被點擊，你不要再習慣性想到應該在相應的aspx.cs中有個時間處理方法，你應該想到的是該有某個Controller中有個Action來處理這個事件。實際上，在ASP.NET MVC中，提倡不要在aspx.cs中寫任何邏輯代碼。甚至應該當他們不存在。
3.數據綁定
對於列表式表格數據，你一定習慣了GridView的數據綁定，可是，從你使用ASP.NET MVC開始，這不在被提倡了。你應該自己處理數據的顯示。當然，我們也可以期待未來的ASP.NET MVC正式版中會有一個強大的Helper來幫我們做數據顯示。
ASP.NET MVC的收益
你一定想知道，我們爲使用ASP.NET付出瞭如此慘烈的代價，那麼我們能得到什麼？從我個人認爲，你至少得到了以下東西：
1.清晰的、關注被分離的代碼；
2.更容易的測試及維護；
3.更符合MVC的表示層；
4.你可以向Java程序員自豪的說：我現在也用MVC模式了，而且不用寫任何XML！
