ASP.Net MVC與WebForm的區別

使用ASP.NET MVC框架，建立預設專案，第一直觀感覺就是地址都是Rewrite過的。對原始碼和配置檔案稍加分析不難看出，MVC使用了httpModules來攔截地址請求，具體用到了System.Web.Routing類庫（MVC2中，MVC1怎麼用的忘記了。）而這部分類庫被包裝在.NET Framework3.5 SP1中，MVC2需要SP1支援也就理所當然了。SP1提供的System.Web.Routing類庫可以方便地進行地址請求攔截，對編碼處理方面也很優秀。UrlRoutingModule類攔截請求，在這之前，Application_Start的時候，會給RouteTable的全域性物件一個攔截的設定。而這個設定使用RouteCollection物件進行儲存，MVC對這個類進行了擴充套件——RouteCollectionExtensions。這些可以不考慮，接下來，當使用者訪問頁面時，UrlRoutingModule類攔截請求，在RouteTable中檢視是否符合規則，符合的話，就會呼叫MvcHandler，這個呼叫在httpHandlers配置節點被註冊，條件是地址符合“*.mvc”規則。MvcHandler的ProcessRequest方法就會呼叫Controller來執行。事實上整個過程都是黑盒子，使用者感覺不到。在Controller中某方法執行後，返回結果，再進入具體的aspx頁面。

    分析了MVC的工作工程，就可以對比其與WebForm的區別了。我們知道，MVC模式的業務被放置到Controller中去執行，而aspx頁面只負責顯示。那麼在MVC中的業務實際執行時間被提前到了HttpMolde中，而WebForm的請求只在httpHandler容器中被執行。也就是說MVC中Controller與View的分離是使用的ASP.Net請求管道隔離的，這樣的話無疑在不影響效率（一次請求，而Response.Redirect是二次請求）的情況下達成了程式碼的邏輯層次的分離。

    MVC工作的優點是顯然的，更加有利於理解分層邏輯，把握程式碼的層次感。Controller到aspx頁面之間的過程，已經被框架隔離。至於Controller或者View頁面與Model呼叫的過程，還是需要自己來把握。ASP.NET的MVC框架實現了Controller程式碼的單獨管理。

    而看WebForm開發模型，則只在HttpHandler容器中執行，對其進行分層，在大的方面缺乏支援，而只能依靠邏輯上分離。並不是不能分離，而是由一定的侷限性。HttpHandler的攔截，是跟訪問字尾名有關的。當請求一個頁面時，那就是一個Handler，而WebForm模型實現顯示與邏輯分離，才有的是WinForm的事件驅動。顯然，事件必須被註冊到頁面裡，比如Button1_Click這樣的程式碼。而在Button1_Click執行之前，Page_Load方法會被執行。

    顯示程式碼被寫入Page_Load方法中，那麼就會造成需要寫額外的廢程式碼，比如if (!Page.IsPostBack)這樣的判定。而在Button1_Click執行後需要顯示的部分，則比較難處理，寫出另一個方法，也是必須要在Button1_Click裡呼叫的。替代的解決方案是使用Response.Redirect，在一個aspx頁面中處理邏輯，處理完就跳轉到另外一個顯示的頁面。這樣做的壞處是，在兩個頁面中資料很難共享，而跳轉是通過標記302來實現，因此多一次請求。而另外還可以通過Server.Execute，Server.Transfer或者Context.RewritePath這樣的處理方式，則兩個頁面轉換是在伺服器端完成，可以共享資料，可以說和MVC框架的處理方式大同小異，缺點是需要手動配置這些重新定向的屬性。

    從以上分析可以看出，MVC框架具有很強的優越性，而WebForm也不是一無是處，在簡單的應用中更加容易開發。WebForm也是可以實現和MVC一樣的分層方式，只是處理時需要多寫一些程式碼而已。而我認為，在用WebForm開發分層遇到的最大問題是頁面與頁面之間資料的傳遞問題，而掌握好WebForm中使用伺服器端跳轉的應用技巧（Server.Execute，Server.Transfer或者Context.RewritePath）進行開發就可以解決資料傳輸問題，ASP.NET MVC與WebForm比較起來，WebForm更容易理解，不會產生複雜的配置，也是一個很不錯的選擇。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-617322/，如需轉載，請註明出處，否則將追究法律責任。