MVC框架的優點-老外的原文翻譯

來自森大科技官方博客
http://www.cnsendblog.com/index.php/?p=128
GPS平臺、網站建設、軟件開發、系統運維，找森大網絡科技！
http://cnsendnet.taobao.com
傳統的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現在實現起來很簡單，而且沒有任何影響客戶端狀態的自動回發。關注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發布后，將.NET托管代碼它的請求處理管道的原生部分，為其提供第一流的支持，這也是ASP.NET的特殊待遇。因為MVC應用基于ASP.NET平臺核心，因此它也會同樣享受這些待遇。第23章我們會詳細說明如何在Windows服務器上的IIS中部署MVC應用程序。

（六）　現代化的API

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

ASP.NET MVC是專為.NET 4.0打造的，所以它的API可以使用最新的編程語言和運行時創新的所有益處，包含擴展方法，lambda表達式，匿名和動態類型，語言集成查詢（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的源代碼。

GPS平臺、網站建設、軟件開發、系統運維，找森大網絡科技！
http://cnsendnet.taobao.com