MVC與WebForm比較

老外的原文翻譯過來時這樣的：

ASP.NET Web Forms有哪些不足？

 

傳統的ASP.NET Web Forms是一個非常好的主意，但現實需求非常複雜。隨著時間的推移，現實世界的項目暴露出Web Forms的一些不足之處：

 

“沉重的”檢視狀態：現實中在http請求之間維持狀態（術語叫檢視狀態）導致了服務端和用戶端巨大的資料區塊來回傳遞。典型情況下這個資料區塊會大到數百K位元組，而且這個資料區塊會在每次請求時來回傳輸，導致網站訪問者訪問速度下降，同時增加了伺服器的頻寬負擔。

 

頁面生存周期：作為頁面生存周期的一部分，串連用戶端事件和服務端事件處理代碼的機制，有時會非常複雜和微妙。很少有開發人員能夠在運行時成功操縱控制項的階層而不發生檢視狀態錯誤，有時還會發現一些事件處理代碼在運行神秘的失敗了。

 

對HTML控制有限：服務端控制項在用戶端將自身轉化為HTML標記，但往往並不是你想要的。在ASP.NET 4.0以前版本中，它的HTML輸出通常並不符合WEB標準，和層疊樣式表（CSS）也沒有良好的結合，而且服務端控制項自動建立不可預知的、複雜的標記ID值，導致Javascript難以訪問。這些問題在在ASP.NET
4.0裡有所改善，但要擷取你期望的HTML標記可能依然比較棘手。

 

有問題的抽象：Web Forms試圖儘可能隱藏HTML和HTTP的實現細節。當你想要實現自訂的行為時，你必須頻繁地從這種抽象裡跳出來，強制你對回傳事件機制實施進行逆向工程，採取一些繁瑣的方法(obtuse
acts)產生你想要的HTML文本。這些抽象甚至會令極富經驗的WEB開發人員感到令人沮喪的挫折。

 

低級的可測試性：ASP.NET的設計者壓根沒有把自動化的測試作為這個軟體開發平台的必要工具。這並不奇怪，他們設計的緊密耦合的體繫結構根本不合適進行單元測試，整合測試也是個問題。

 

ASP.NET在不斷髮展。2.0版增加了一套標準應用程式組件集，可以減少你需要自己輸入的代碼量。2007年發布的AJAX版本是微軟對當時Web
2.0/AJAX瘋狂流行的響應，它支援富用戶端互動。最近發布的ASP.NET 4.0版，可以產生大部分可以預見的符合標準的HTML標記，但許多其固有的局限性依然存在。

ASP.NET MVC的主要優勢

 

 

 

ASP.NET在商業上取得了巨大成功，但正如前所述，其它的WEB開發平台也在不斷向前發展。儘管微軟一直在努力把緾繞在WEB Forms上的“蜘蛛網”清除掉，但其內在的設計理念已經落伍了。

 

2007年10月份，在美國德克薩斯州奧斯丁市召開的第一屆ALT.NET會議上，微軟公司副總裁Scott Guthrie發布並示範了一個基於ASP.NET的嶄新的MVC
WEB開發平台，明確的被設計為針對類似Rails這樣的技術的直接響應，也是對業界關於Web Forms的批評的回應。本章的餘下部分描述這個新的平台如何解決Web Forms的種種不足，並令ASP.NET重返頂峰。

 

(一) MVC體繫結構

 

把MVC構建模式和ASP.NET MVC架構之間的區別搞清楚是十分重要的。MVC模式並不是新生事物－這要追溯到1978年施樂公司帕洛阿爾托研究中心的Smalltalk項目－之所以在今天的WEB開發領域廣受歡迎，有以下原因：

 

MVC應用程式的使用者互動符合自然周期：使用者執行一個動作，作為響應，應用程式改變它的資料模型，並向使用者提供一個更新了的視圖。應用程式就一直這樣迴圈的運行。這種模式非常適合WEB應用程式傳遞

 

一連串的HTTP請求和響應。

 

WEB應用程式必然要涉及若干不同的技術領域（資料庫，HTML，可執行代碼），通常這些技術都分布在不同層面。而MVC的概念很自然的就和這些技術的組合模式對應起來了。

 

ASP.NET MVC架構實現了MVC模式，而且這樣做，有利於更好分離關注。實際上，ASP.NET MVC實現了一個特別為WEB應用開發定製的MVC模式。在第4章你將會瞭解這個體系的更多的理論，並親身體驗。

 

通過包含和改進MVC模式，ASP.NET MVC架構相對於Ruby on Rails這樣的架構具備了強大的競爭力，同時也將MVC模式引入到主流的.NET領域。通過使用其它平台的開發人員提供的對ASP.NET
MVC的體驗評估和實際應用中反饋，ASP.NET MVC在許多方面甚至已經超越了Rails。

 

（二）　可擴充性

 

你的案頭型電腦都是由一些相互獨立的部分組成，它們之間通過標準的公開的文檔化的介面相互聯絡。你可以很輕鬆的把你的顯卡和硬碟換成另一個製造商生產的產品，並確信它們可以插進相應的槽位並正常工作。MVC架構的原理和PC一樣也是構建在一系列相互獨立的組件的基礎之上－如一個可信的.NET介面或繼承抽象基類的使用者類－這樣你就可以輕而易舉用你自己的實現替換這些組件，諸如路由系統，視圖引擎，控制器工廠等等。

 

ASP.NET MVC設計者對如何使用MVC架構的每個組件向你提供了三個選擇：

 

使用預設組件實現（對於大部分應用來說已經足夠了）

 

從預設實現繼承實現一個子類，以對某些行為進行微調

 

使用新的介面或抽象基類實現替換這些組件

 

這些看起來有點像ASP.NET 2.0中的供給者模式（provider model），但它更進了一步－完全進入了MVC架構的核心。從第10章起，你將會瞭解到各種各樣的組件，並且知道為什麼要調整或替換它們。

 

（三）　對HTML代碼和HTTP的嚴密控制力（Tight Control over HTML and HTTP）

 

ASP.NET MVC知道產生整潔、符合標準的標記的重要。它內建的HTML helper方法的輸出完全符合標準，但同Web Forms相比較其更多的重要變化體現在其設計哲學上。以往你對Web
Forms自動產生的一大堆令人作嘔的封裝的HTML標記只有很小的控制權，作為替代，MVC架構鼓勵你使用CSS設計簡潔、優雅的標記。

 

當然，如果你想在你的頁面擺上一些現成的複合UI元素的小玩意，像日曆或串聯功能表，ASP.NET MVC中的“無特殊要求”的標記方法讓你可以輕易的使用最好的UI庫，比如JQuery或雅虎的YUI庫。微軟已經把JQuery內建為ASP.NET
MVC預設項目模板的一部分，JavaScript程式員會對ASP.NET MVC和當前流行的JQuery庫結合如此緊密感到欣慰，甚至在微軟自己的內容分髮網絡（CDN）伺服器上你都可以直接引用Jquery.js檔案。我們將在第20章涉及到JQuery。

 

ASP.NET MVC產生的頁面不包含任何檢視狀態資料，因此它們比典型的ASP.NET Web Forms頁面會小數百K。儘管今天的寬頻連線已經非常快了，但這種頻寬的節約依然會給終端使用者帶來巨大的體驗改善。

 

和Ruby on Rails一樣，ASP.NET MVC和HTTP合作和諧。你對往返於瀏覽器和伺服器之間請求擁有完整的控制權，這樣你就按你的喜好可以微調你的使用者體驗。AJAX現在實現起來很簡單，而且沒有任何影響用戶端狀態的AutoPostBack。關注Web開發領域的任何開發人員幾乎肯定會發現，ASP.NET
MVC會極大減少工作量，在同樣的時間內完成的任務會更加令人滿意。

 

（四）　易測試性

 

MVC使你在應用程式的可維護和可測試方面邁出了一大步，因為你可以自然的根據程式要實現的不同功能將其分離成許多不同的、相互獨立的軟體塊。然而，ASP.NET MVC的設計師們並不滿足於到底就止步了。為了支援單元測試，他們在架構中引入了面向組件設計的概念，並確保每個分離的代碼塊都以滿足單元測試和類比工具的需要的形式構建。

 

出於為開發人員考慮的角度，他們還在Visual Studio嚮導中增加了建立單元測試嚮導，它可以使用許多開源的單元測試工具，如NUnit和xUnit，甚至微軟自己的MSTest。即使你以前從來沒有寫過單元測試代碼，你也會有一個良好的開始。

 

本書中，你會看許多為ASP.NET MVC控制器（controller)和行為(action）編寫的簡潔、簡單的單元測試樣本，這些樣本會使用各種測試和類比策略來冒充架構組件的實現，以確定實際運行中可能出現的任何情況。

 

易測試性不只是體現在單元測試中，ASP.NET MVC應用程式和UI自動化測試載入器之間工作也非常好。你可以類比使用者互動的情景編寫測試指令碼，再不用去猜測HTML元素的結構，使用的CSS類，或者架構將要產生的ID，也用不著擔心頁面的結構會出現莫名其妙的變化。

 

（五）　強大的路由系統

 

URL的風格伴隨著Web應用技術的發展也在不斷髮展。像下面的URL：

 

/App_v2/User/Page.aspx?action=show%20prop&prop_id=82742

 

將會逐漸稀少，它將被一種簡單的、整潔的格式所代替，就像下面的這個：

 

/to-rent/chicago/2303-silver-street

 

之所以關注URL的結構問題，有以下幾個很好的原因：第一，搜尋引擎給在URL中搜尋索引鍵分配了很大的權重。搜尋“芝加哥的租金”會更容易匹配上面那個簡單的URL。第二，現在許多網路使用者的理解能力足夠搞明白一個URL的意思，而且他們很欣賞在瀏覽器地址欄輸入地址時的智能導航選項。第三，當人們理解了一個URL的結構，他們更有可能去連結它，把它和朋友共用，甚至可以通過電話大聲的讀出來。第四，它不會把你的應用程式的技術細節，目錄，檔案名稱結構公開到整個互連網上，因此，你可以自由的改變底層的實現而不會影響到你已經擁有的串連。

 

早期的架構難以實現精準的URL，不過ASP.NET MVC預設使用System.Web.Routing命名空間很容易提供精準的URL。它可以讓你控制你的URL的樣式，並將其和你的應用相關聯，為你提供創造一個有意義的、對使用者有用的地址樣式的自由，不需要遵守預定義的模式。另外，只要你願意，你完全可以容易的定義時髦的REST風格的URL樣式。你會第11章看到一個詳細的路由方案和關於URL的最佳練習。

 

（六）　構建於ASP.NET平台最好的部分之上

 

微軟現有的ASP.NET平台已經為開發實用和高效的web應用程式提供了一整套成熟的、久經考驗的組件和工具集。

 

首先也是最明顯的地方，因為ASP.NET MVC構建在.NET平台之上，所以使用者可以靈活的使用任意.NET語言編寫代碼和訪問相同API功能－不光是MVC裡面的，也包括大量的系統.NET類庫和浩瀚的第三方.NET庫。

 

其次，現有的ASP.NET平台的一些功能－比如主版頁面，表單驗證，成員資格，角色，profiles，還有國際化－能夠減少你需要開發和維護任意應用程式的代碼量，這些功能在MVC架構中同樣有效，因為它本來就是一個傑出的Web
Forms項目。你可以在ASP.NET MVC的項目中繼續使用一部分Web Forms內建的伺服器控制項，以及你在早期的ASP.NET項目中建立的自訂控制項。（不過不能再依賴Web
Forms中的特有概念，比如檢視狀態）

 

開發和布署是交替進行的。ASP.NET不僅和Visual Studio緊密結合在一起，它也作為一種原生的web編程技術為Windows
XP,Vista,7和伺服器作業系統中安裝的Internet資訊服務（IIS）所支援。IIS7發布後，將.NETManaged 程式碼它的請求處理管道的原生部分，為其提供第一流的支援，這也是ASP.NET的特殊待遇。因為MVC應用基於ASP.NET平台核心，因此它也會同樣享受這些待遇。第23章我們會詳細說明如何在Windows伺服器上的IIS中部署MVC應用程式。

 

（六）　現代化的API

 

自微軟2002年發布 .NET平台以來，它一直在持續的發展，支援甚至是定義了現代編程技術頂級水準。

 

ASP.NET MVC是專為.NET 4.0打造的，所以它的API可以使用最新的程式設計語言和運行時創新的所有益處，包含擴充方法，lambda運算式，匿名和動態類型，Language-integrated Query (LINQ)（LINQ）。許多MVC架構的API方法和編碼模式儘可能的比早期平台整潔，更富表現力。

 

（七）　ASP.NET　MVC是開源的

 

和微軟先前的平台不同，ASP.NET　MVC的原始代碼你可以隨意下載，甚至可以對其進行修改，重新編譯為你自己的版本。當你的調試足跡深入到一個系統組件內部，想對它的代碼進行步進（甚至閱讀原作者的注釋）時，代碼開源是非常有用的。另外，如果你想構建一個更進階的組件，看看可能會發生什麼，或者觀察內建群組件是如何工作的，這點也非常有協助。

 

同時，如果你不喜歡某些工作的實現方式，或者你發現了一個錯誤，又或者你想訪問一些其它方式無法訪問的東西，開源好處是非常強大的。因為你自己就可以簡單的改變它。

 

不過，如果將來有一天你將你的架構升級到新版本，你還要重複你所作的改變再重新應用它們。ASP.NET MVC是按照微軟公用許可（Ms-PL，http://www.opensource.org/licenses/ms-pl.html）發布的，這是一個經過開源促進組織獲批准的開源許可。也就是說你能夠修改原始碼並部署它，甚至把它作為一個衍生項目向公眾發布。然而，微軟在其官方版本上不接受任何補丁，現階段，微軟只維護其產品開發和品質保證團隊的負責的代碼，你可以從http://aspnt.codeplex.com/網站上下載MVC的原始碼。