《精通 ASP.NET MVC 4》----1.3 ASP.NET MVC的關鍵優點

本節書摘來自異步社群《精通 asp.net mvc 4》一書中的第1章，第1.3節，作者： 【美】adam freeman ，譯者： 李萍 , 徐燕萍 , 林逸 ， 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

精通 asp.net mvc 4

asp.net已經獲得了巨大的商業成功，但正如所讨論的，其他web開發領域也在進步，即使是微軟也在不斷清理web form的垢病，因為其基本設計看上去已經相當陳舊了。

2007年10月，在德克薩斯-奧斯汀舉行的第一次alt.net國際會議上，微軟副總裁scottguthrie宣布并示範了嶄新的mvc web開發平台，它建立在核心asp.net平台之上，明确地作出對rails等技術進展的直接回應，以及對web form批評的反應。以下小節将描述這個新平台如何克服web form的局限性，并把asp.net重新帶回到先進行列。

差別mvc體系結構模式與asp.net mvc架構非常重要。mvc模式并不新——這要回溯到1978年xerox parc的smalltalk項目——但它作為一種web應用程式的模式，如今已得到了廣泛的普及，原因如下。

使用者與mvc應用程式的互動遵循一種自然的循環：使用者采取一個動作，應用程式對其作出響應，修改其資料模型，并把一個更新的視圖提供給該使用者，然後重複這一循環。這非常适合于以一系列http請求與響應進行傳遞的web應用程式。

web應用程式必須組合多種技術（如資料庫、html、可執行代碼等），這通常被分成一系列層次。這種組合所産生的設計模式能夠自然地映射到mvc的概念上。

asp.net mvc架構實作了這種mvc模式，而且在實作過程中還極大地改善了關注分離。事實上，asp.net mvc實作了mvc模式的現代化變異，使它特别适用于web應用程式。讀者将在第3章更多地了解這種體系結構的理論與做法。

通過采納和調整mvc模式，asp.net mvc架構對roby on rails以及類似平台形成了強有力的競争，并把mvc模式帶到了.net世界的主流。利用開發人員使用其他平台的經驗和最佳實踐，asp.net mvc在許多方面的推進甚至已經超越了rails。

桌面電腦的内部元件是一個個獨立的部件，它們隻通過标準的公共文檔接口進行互動。人們可以很容易地拔出顯示卡或硬碟，并用另一制造商的産品來替換，相信它會在插槽中正常工作。mvc架構也被建構成一系列獨立的元件——滿足一個.net接口，或建立在一個抽象類之上。是以，開發者可以很容易地用一個自己的不同實作來替換相應元件，如：替換路由系統、視圖引擎、控制器工廠等。

asp.net mvc設計者對每一個mvc架構元件都提供了3種選擇。

使用元件現行的預設實作（它應該足以滿足大多數應用程式）。

派生預設實作的一個子類，以調整其行為。

用接口或抽象基類的一個新實作來完全替換該元件。

這就像自asp.net 2.0開始的提供器模型一樣，而且還向前跨了一大步——深入到了mvc架構的核心部分。從第12章開始，讀者将了解所有這些各種各樣的元件，以及如何和為什麼要調整或替換這些元件。

asp.net mvc認識到，産生整潔、與标準相容的标記的重要性。其内建的html輔助器方法可以産生與标準相容的輸出，但與web form相比，還有一種更重要的理念上的變革。mvc架構鼓勵使用構思簡單、優雅、可設定css樣式的标記，而不是生成大片難以控制的html标記。

當然，如果使用者确實想将一些現成的部件用于複雜的ui元素，如日期選擇器或級聯菜單等，asp.net mvc的“無特殊需求”标記方法可以很容易地使用最佳品種的ui庫，如jquery庫或yahoo ui庫等。微軟已經将jquery裝配為預設的asp.net mvc項目模闆的一個内建部件，asp.net mvc與流行的jquery庫齧合得如此良好，甚至能夠直接引用微軟的内容分發網絡（cdn，content delivery network）伺服器上的jquery.js檔案。javascript開發者們如果了解到這些，一定會感到非常開心。

asp.net mvc生成的頁面不含任何視圖狀态資料，是以，這些網頁可能比典型的asp.net web form頁面要小幾百kb。無論今天的高速寬帶如何，這種對帶寬的節約仍然極大地改善了最終使用者的體驗。

與ruby on rails一樣，asp.net mvc與http工作得十分協調。使用者對傳遞于浏覽器與伺服器之間的請求有完全的控制，是以隻要使用者願意，就可以仔細地調整使用者體驗。ajax很容易使用，而且沒有任何自動回發來擾亂用戶端狀态。任何一個專注于web的開發人員都會覺得這是極大的解放，且讓人工作時心情愉快。

mvc體系結構為使用者提供了很棒的起點，以使應用程式可維護和可測試，因為使用者可以自然地把應用程式的不同關注分成不同的、獨立的軟體片段。asp.net mvc的設計者們還不止做了這些。為了支援單元測試，他們對該架構采取了面向元件的設計，并確定把每個獨立的片段構造成滿足單元測試和模仿工具的需求。

添加了visual studio向導，讓使用者建立初步的單元測試項目，該項目內建了開源的單元測試工具，如nunit和xunit，以及微軟自己的mstest。即使以前從未編寫過單元測試的人，也會有一個很好的開始。

讀者将會在本書中看到，如何為asp.net mvc的控制器以及動作編寫整潔、簡單的單元測試示例。這些單元測試使用各種測試和模仿政策，提供對架構元件的僞造或模仿實作來模拟各種情景。

可測試性并不僅僅是單元測試的事情。asp.net mvc應用程式也可以與ui自動化測試工具良好協作。使用者可以編寫模拟使用者互動的腳本，而不必猜測架構會生成什麼樣的html元素結構、什麼樣的css的class，或什麼樣的id等，也不必擔憂這種結構的意外變化。

随着web應用程式技術的改進，url的樣式也已經發生了演變，如下面所示的url。

<code>/app_v2/user/page.aspx?action=show%20prop&amp;prop_id=82742</code>

這種url已經明顯很少見到了，取而代之的是一種更簡單、更清晰的格式，如下所示。

<code>/to-rent/chicago/2303-silver-street</code>

采用這種url結構有一些很好的理由。首先，搜尋引擎對url中找到的關鍵詞有明顯的權重。一個對“芝加哥租房”的搜尋，更可能找到的是一個較簡單的url。其次，許多web使用者現在對url有了足夠的領悟，并且樂于直接在浏覽器的位址欄中輸入。再次，當了解了url的結構時，人們才會更可能連結它，與朋友共享它，或在電話中報讀它。最後，這種url并不會把應用程式的技術細節、檔案夾、檔案名結構暴露給整個公用網，是以，人們可以自由地修改底層實作而不會破壞輸傳入連結接。

整潔的url在早期的架構中難以實作，但asp.net mvc會預設使用system.web.routing工具給出整潔的url。這讓使用者能夠完全控制url方案及其與應用程式的關系，使使用者能自由地建立對使用者有意義和有用的url模式，而無須遵守預定義模式。當然，這也意味着，如果使用者願意，可以很容易地定義現代rest風格的url方案。讀者将在第13章和第14章了解路由的整個處理和url的最佳做法。

微軟目前的asp.net平台為開發高效的web應用程式提供了一系列成熟的、經充分驗證的元件和工具集。

首先，也是最明顯的，由于asp.net mvc是基于.net平台的，是以可以靈活地使用任何.net語言來編寫代碼，并通路同樣的api特性——不僅僅是mvc本身的特性，而是廣泛的.net類庫和大量的第三方.net類庫體系。

其次，已形成的asp.net平台特性，如母版頁（master page）、表單認證（forms authentication）、成員（membership）、角色（roles）、簡檔（profiles），以及國際化（internationalization）等，可以減少開發和維護web應用程式所需的代碼量。而且這些特性在mvc架構中的使用同在經典的web form項目中的使用一樣有效。使用者可以在asp.net mvc應用程式中重用web form内建的伺服器控件，以及早期的asp.net項目中的自定義控件（隻要它們不依賴于web form的專有概念，如視圖狀态）。

自2002年初以來，微軟的.net平台經過了不懈的演變，現在，在許多方面的支援甚至定義了達到最新技術發展水準的現代程式設計。

asp.net mvc 4是針對.net 4.5而建立的，是以它的api可以充分利用最新語言和運作時的創新，包括await關鍵字、擴充方法、lambda表達式、匿名及動态類型，以及語言內建查詢（linq）等。許多mvc架構的api方法和編碼模式與早期平台相比，遵循了一種更清晰、更富表現力的寫作方式。

與之前的微軟web開發平台不同，現在人們可以自由地下載下傳asp.net mvc的源代碼，甚至修改和編譯自己的版本。在調試跟蹤深入到系統元件，以及想步入其代碼内部（甚至讀取原程式員的注釋）時，這種開源都是無價的。如果正在建立進階元件，并想看看有什麼（可進一步）開發的可能性，或者想了解内建元件如何工作等情況時，這種開源也是很有用的。

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。