一、MVC相對於WebForm的變化
1. 使用URL Routing技術：Web程序的URL不再是指向具體的物理頁面.aspx，而是指向某個Controller的某個方法。一個典型的MVC架構的程序,其URL可能如下所示：
http://www.mysite.com/Customer/Index
使用該MVC架構的程序其URL不必有文件擴展名。上面這個URL中的Customer即為Controller的名字。而Index是Customer定義的一個方法名。
2. Web程序的界面.aspx不再使用服務器端的Form:
<asp: form runat="server"></form>
那么與服務器端的Form相關的Postback以及頁面生命周期的事件也不存在了。
3. 頁面中不再有View State。MVC下將不能使用View State來存儲程序狀態信息。
4. 不再提供依賴於服務器端Form的服務器控件事件，開發人員熟悉的Button_Clicked事件在MVC下將不再需要。
二、WebForm網站和MVC網站運行機制的區別
①WebForm網站的運行機制
比如說我們現在要訪問一個WebForm站點：www.google.com.hk/Default.aspx(僅僅是示例)。我們的瀏覽器和服務器都是做了哪些動作呢？
1）首先瀏覽器會向目的服務器發送請求報文。
配置過IIS的都知道，網站掛載在服務器上，我們是通過訪問虛擬目錄的方式訪問網站的。這時候目的主機的IIS接收的是訪問該虛擬目錄下Default.aspx文件的請求；（當然這也是一個非常復雜的過程，包括請求DNS服務器，找到目的主機IP，根據IP地址訪問目的主機。復雜的網絡過程就不敘述，有興趣的自己找資料學習）；
2）服務器端的IIS軟件接收到請求后，把請求交給.NET FramWork進行處理；
3）.NET FramWork會創建Default_aspx類的對象，也就是我們所說的頁面對象。（在WebFrom網站創建完，並且編譯后Default.aspx會被編譯成Default_aspx類）
到現在的整個過程都還是Http請求，IIS的內部機制會去實現一個IHttphandler的接口，其中該接口實現一個ProcessRequestfang方法
MSDN是這樣解釋的
該ProcessRequest（）方法會去調用對應頁面的Page_Load（） 方法
1 protected void Page_Load(object sender, EventArgs e)
2 {
3 //處理的業務邏輯或者是訪問數據庫的代碼
4 //要輸出的Html或者其它內容
5 }
4）返回給瀏覽器（包括Html，CSS，Js等等）
流程示意圖如下：
②MVC網站的運行機制
還比如說我們現在要訪問一個MVC站點：www.google.com.hk/FirstPage/Default(僅僅是示例)。我們的瀏覽器和服務器又做了哪些動作呢？
1)瀏覽器向服務器發送Request請求報文（FirstPage/Default）
2)服務器端的IIS相應Request請求
3）.NET FramWork根據路由配置，解析URL，並創建FirstPage類的對象，並調用相應的Default方法
1 public ActionResult Default()
2 {
3
4 return View();//返回給視圖
5 }
4)然后會訪問視圖文件夾下的Default.cshtml，返回給瀏覽器（其中包括html,css,js等等）
流程的示意圖如下：
這只是一個比較簡單的運行過程。其實在這過程中發生了很多事情，比如說：執行Global.asax中的Application_Start()方法來完成一些初始化的工作等等，會在以后的文章中繼續解析。
以上就是WebForm網站和MVC網站運行機制的區別。
那么到底使用MVC的優點比WebForm到底有哪些優點呢？
①最重要的就是.NET程序員在開發的時候再也不會使用那些被很多人詬病的微軟封裝的控件了。
②MVC設計模式降低了模型（Model,業務和數據）和視圖的耦合關系。包括我們在開發WebForm網站使用三層架構的思想也是為了降低數據和視圖的耦合等；
③可以復用視圖，也就是說同樣的數據可以使用不同的視圖以不同的圖標展示出來。