[轉貼一]
使用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的一些總結和心得。