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是二次請求）的狀況下達成了代碼的邏輯層次的分離。

圖1 MVC工做模型

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更容易理解，不會產生複雜的配置，也是一個很不錯的選擇。

 

[轉貼二]

      MVC縱向切割了開發過程當中的代碼，從服務器到瀏覽器層層分離，層次之間耦合度很低，由於它是順着底層的開發脈絡進行封裝，因此有利於開發者對整個程序過程流轉的理解。可是MVC有一個很是大的缺點，這個缺點是和整個軟件發展思路相背離的，那就是它沒法封裝、沒法封裝因此沒法被重用。有誰看到過mvc下面的組件？有的只是一個個現成的案例，而後拿來修改。由於一個組件確定牽涉到控制和顯示，可是mvc的開發這兩個層次是分離的。MVC只適合輕量級的開發，桌面開發是極少用到mvc模式的。然而web開發偏偏就是輕量級，至今全部的web開發都是輕量級的，由於網絡硬件條件的限制，不須要也沒法作到很是複雜的邏輯。這也是MVC很是很是適合web開發的緣由。
     WebForm是微軟前面一套web開發的機制。它橫向切割了代碼，控制和顯示是封裝在一塊兒的。它從開發者思惟邏輯上而不是實際狀況上對代碼進行封裝，開發webform容易上手的緣由也就在此了，但這個不利於開發者對底層程序流起色制的理解。WebForm中view和controller是放在一塊兒的，WebForm一出現後，隨之而來的是大量的組件誕生，這是mvc模式下看不到的。微軟的經驗之一是硬件發展很迅速。代碼的封裝是靠犧牲運行效率來提升開發效率，犧牲的運行效率經過提升硬件性能來解決。但微軟在webform上犯了經驗主義的錯誤，這個經驗不適合網絡硬件，網絡硬件要考慮兼容性並且是國家的基礎設施，更新的靈活性遠比單機要差。大量的組件由於硬件的瓶頸沒法給WebForm帶來什麼優點。在發展了幾年webform後，微軟以爲這樣下去不行，等到網絡硬件發展起來不知道到猴年馬月了，因此就抄了一下成熟的mvc，經過Entity Framework作數據庫和對象的映射，很明顯，它是爲了充當mvc中那個Model。經過mvc來控制和展現。
      webform生產關係是比mvc先進的，可是它不適合如今的網絡設施生產力，若是要適合說不定要10年後。webform和mvc很好的印證了生產關係必須適合生產力，即便強大如微軟也沒法改變客觀規律。

 

 [轉貼三]

 ASP.NET MVC :從ASP.NET WebForm到ASP.NET MVC技術上的共用和差別 
關於WebForm與MVC的討論，年初的時候已經有一段很長時間的討論了。我無心再去爭論哪一種架構模式更適合咱們作開發，無論是哪一個領域，技術的存在都有其不一樣的歷史意義和市場價值。我更關注的是，在合適的機會去掌握更多的技術，從技術實現的角度來尋找當前階段最爲順手的一種作事方法。因此請注意，在這裏不討論WebForm與MVC的優劣，適用場景。在這裏只有ASP.NET WebForm與ASP.NET MVC，一樣屬於ASP.NET框架下的兩種不一樣的Web開發技術，是如何充分發揮ASP.NET平臺的強大功能，以及對於掌握ASP.NET WebForm的開發人員，轉向ASP.NET MVC架構的學習成本。這就是我本篇文章的立意所在，同時我也是但願爲我以後的幾篇MVC系列文章提供一些註腳和鋪墊。

以前，從事ASP.NET開發，在沒有特殊說明的狀況下，指的就是ASP.NET WebForm的開發。以前ASP.NET技術的發展，直接就體如今WebForm技術上的進步。在ASP.NET MVC 出現以後，以前你們所掌握的ASP.NET技術對於ASP.NET MVC仍然有效，而且是最基礎的部分。包括：頁面處理流程，Web請求上下文對象，Web配置系統，公用性的組件模塊，部分的服務器控件等等。我想從這幾大塊來詳細闡述ASP.NET MVC對於ASP.NET技術的繼承：

頁面處理流程：ASP.NET MVC 的頁面處理流程仍然是在ASP.NET原有的處理流程上的擴展，在在上游的請求通道不變的前提下，經過特定的IHttpModule和IHttpHandler來處理ASP.NET MVC的請求。與WebForm頁面處理不同的地方就在於，在WebForm中，每個頁面都是一個IHttpHandler實例，頁面的事件流程就是從IHttpHandler的ProcessRequest(HttpContext httpContext)方法開始。而在ASP.NET MVC中，全部的Controller都並非IHttpHandler的繼承實例，它的Action是在MvcHandler中被執行的，固然咱們也能夠自定義是MvcHandler。 
Web請求上下文對象：在ASP.NET MVC中，處理請求的線程模型沒有改變。請求的上下文對象，與原有的ASP.NET WebForm仍然是共用的。 
Web配置系統：ASP.NET MVC仍然使用原有的配置系統，在Web.config中只是部分的配置節點不適用於ASP.NET MVC，好比頁面訪問受權配置。 
公用性的組件模塊：在ASP.NET MVC中，包括Membership，healthMonitoring，httpModule,trace在內的內置和自定義的組件模塊仍然是繼續可用。 
部分服務器控件可用：首先，最爲明顯的是咱們使用的是.aspx頁面做爲MVC的View。雖而後綴仍然爲.aspx，可是它的意義已經再也不是一個可執行的頁面文件了，再也不是一個純粹意義上的IHttpHandler。可是它仍然是繼承於原有的Page基類。在ASP.NET MVC中，將它做爲View來展現，仍然以ProcessRequest爲入口來執行頁面，也就意味着除了回發事件的相關事件和函數不會被執行外，頁面的執行事件流程仍然是有效的。以此，若是不考慮服務器控件的性能和其它因素影響，咱們仍然是可使用大部分的服務器控件，固然用不用取決於你。
以上是我總結到的一些ASP.NET MVC對ASP.NET原有技術的繼承，可是作爲ASP.NET技術的發展，有不少東西是自己就是乏善可陳的，不說，也應該知道就是那樣。可是說出來，更有助於你們來區分ASP.NET，(ASP.NET)WebForm，ASP.NET MVC(爲何WebForm前面的ASP.NET加括弧呢？你們來講說緣由)這三者的概念區別和關係。

下面我還想來講說，ASP.NET MVC較以前的ASP.NET(WebForm)開發技術在實踐上有哪些比較明顯的區別：

.aspx文件，已經再也不是一個可被獨立請求的頁面了。你不能對它從物理上進行權限控制。 咱們的少用服務器控件了。咱們仍然可使用，你徹底能夠不考慮runat='server'的性能影響。可是並不保證全部的服務器控件均可用。可能還有其它的緣由讓你選擇不使用服務器控件。 咱們沒有PostBack和頁面回發事件機制了。提交表單咱們基本使用Web的原生方式了，傳輸的數據量也更爲合理。咱們少用ViewState了。少用，意味着咱們仍是能夠用的。只是因爲MVC架構的限制，咱們在ViewState存的值並不會被序列化到客戶端去，它有效性是在一次請求的上下文中。在某些特定的場合內，ViewState仍是能發揮它的餘熱，而且並不影響性能。 要處理一個用戶的自定義請求，好比RSS請求。咱們再也不須要定義一個IHttpHandler或特定的.aspx頁面。處理用戶的每一個請求都只是在一個Controller的Action函數當中，在Action函數中，你能夠輸出View，能夠輸出JSON字符串，還能夠輸出任何自定義格式的文件和輸出流。 業務邏輯與UI邏輯從架構上獲得了很好的分離，可是你要不想這麼作，仍然也是有效的。只是在這種狀況下，你仍是選擇WebForm吧。ASP.NET MVC和WebForm在不少實現上的統一，是咱們已經掌握ASP.NET原有開發模式的開發人員順利的上手MVC保證。以後陸續會有幾篇我在用MVC實踐本身一個網站後，對MVC的一些總結和心得。