ASP.NET 為什麼要有 MVC

　　不得不承認，最初MVC並沒有被微軟的研發人員設計到ASP.NET中。至於為什麼非要在後來強行加入到ASP.NET中，我們無從得知。
　　不過在類似Java平台中的Struts之類的MVC架構如火如荼的發展，而且被很多新老技術人員給它們套上了一層層神聖的光環，如果微軟沒有採取一些行動，確實有些丟這個“軟體帝國”的面子。

軟體帝國的超級武器——WebForm
　　WebForm——確實是一個非常有創意，並且非常實用的東西。不過可以肯定，不管是現在，還是在不遠的將來，WebForm都將會一直保持著它獨具的特色，和它無於倫比的便利性。
　　在WebForm中，微軟開創性的將傳統型應用程式的開發模式引入Web應用程式的開發中。例如拖控制項、加事件處理常式、然後運行……這一切都是那麼的愜意、那麼的讓人拍案叫絕。
　　而且，ASP.NET還可以將前台的視圖展示代碼和背景事件處理常式完全隔離在兩個不同的檔案中。如此，一切看似神奇的東西都被系統“自動”完成了。
　　這一切，對於一個初級的Web程式開發人員來說，比讓其編寫大堆的頁面代碼要舒服的多。所以ASP.NET WebForm一度吸引了無數的開發人員加入進來。

超級武器也有盲區
　　回到上個世紀，大部分的Web應用都是使用的頁面中混合代碼的資料編程。比如ASP和PHP（早些時候）一樣直接在頁面中向資料庫請求並用HTML顯示的程式結構。這種方式往往開發速度比較快，但是由於資料頁面的分離不是很直接，所以很難體現出程式業務模型的樣子，當然也很難實現模型的重用性。產品設計沒有彈性，很難滿足不斷變化的使用者需求。
　　不過這些缺陷，都被JSP和ASP.NET這兩種天生就物件導向的語言很好的解決掉了。現在一般的應用程式都使用三層（或多層）結構來處理常式中的商務邏輯。
　　在Web應用程式的介面層，經常需要在不同的時刻為不同的使用者呈現不同的內容。所以能不能把這個對“不同的時刻”、“不同的使用者”、“不同的內容”的判斷和具體的內容進行分離，使之更容易的控制和協調就成了一個新的問題。
於是乎，Java隨即就引入了MVC模式的應用程式框架，很完美的解決了這個問題。
　　而與此同時，ASP.NET卻在專註於WebForm的研究和應用，同時也取得了一些非常可觀的成就。但是其極大程度的整合了MVC模式中的V和C的關係，雖然獨具特色，卻使應用程式的UI層耦合性加強，或者說有點與MVC的思想背道而馳（或許這麼說有點貶意，不過這裡的確沒有貶低WebForm的意思），惹了不少開發與測試人員的抱怨。

 軟體帝國的快速反應
　　正值Java中的MVC架構快速發展，同時ASP.NET WebForm也大行其道的時候，微軟推出了ASP.NET MVC架構。
　　也許是因為Java中的MVC發展的太火了，微軟有點像是在跟風的意味，於是很多人就開始有點見風使舵，大呼ASP.NET將迎來WebForm的末日、MVC的新紀元，這樣其實是毫無依據的。
　　首先，MVC和WebForm根本就不具可比性，WebForm是一個全新的Web開發模式，從頭到尾都是套完整的東西。雖然其在某些方面有一些局限性，但是其仍然是一個優秀的開發模式，是MVC不可取代的。
　　其次，MVC和WebForm各有所長，MVC主要解決的是視圖層的耦合性問題，但是其不具備快速開發和簡單易用的特性，需要開發人員掌握的知識比較系統全面；而WebForm卻簡單易用，入門非常容易，其具有MVC不可替代的位置。
　　總之，MVC和WebForm不會衝突，也不會有那一方很快消亡（除非那一天有誰整合了它們二者的優點到某一方上面）。
　　而且當下據微軟對二者的態度來看，似乎應了鄧小平先生說過的一句話——“兩手抓，兩手都要硬”。

其它

　　說一點可能讓Java程式員心裡不爽的話：學了ASP.NET，感覺非常好（雖然它很“年輕”），它直接解決掉了許多Java中的詬病，比如像長篇小說似的設定檔……

（註：本文的一部分觀點和語言是借鑒某網友部落格的，具體是那兒的記不清了）

 （轉載請註明出處：http://www.cnblogs.com/zhhh/）