ASP.NET MVC 5 02 - ASP.NET MVC 1-5 各版本特色

時間 2019-11-12

標籤 asp.net asp mvc 版本特色欄目 ASP 简体版

原文原文鏈接

參考書籍：《ASP.NET MVC 4 高級編程》、《ASP.NET MVC 5 高級編程》、《C#高級編程(第8版)》、《使用ASP.NET MVC開發企業及應用》、度娘谷歌等。html

　　

　　前言：jquery

　　　　前一篇只簡單的介紹了ASP.NET和ASP.NET MVC，有朋友說要點乾貨。好吧。那就來點乾貨。程序員

　　　　正好我也是真心想系統性的整整MVC4和5，之前也沒有深刻弄過，因此此次我也是豁出去了，相關的書都入手了，只求最精。web

　　　　人家雙11都是買吃的喝的用的裝逼的。我們這些程序員卻。。。真是服服的了。數據庫

　　　　別被滾動條嚇到。看書先看目錄。畢竟整了兩天多的。再說了，瞭解一下各版本區別，對後面學習老是有好處的。編程

　　　　此次我把MVC 1-5各版本的更新特色都收集整理了一下，也算是爲了把每一個版本的和我以前掌握的MVC4作個對比，方便後面的進一步的學習吧。 bootstrap

本篇目錄：設計模式

1. ASP.NET MVC如何適應ASP.NET瀏覽器

2. MVC模式簡介緩存

3. MVC在Web框架中的應用

4. ASP.NET MVC5 的發展歷程

4.1 ASP.NET MVC 1 概述

4.2 ASP.NET MVC 2 概述

4.3 ASP.NET MVC 3 概述

4.3.1 Razor視圖引擎

4.3.2 驗證的改善

4.3.3 支持.NET 4數據註解

4.3.4 經過改進模型驗證簡化驗證

4.3.5 非侵入式Javascript

4.3.6 jQuery驗證

4.3.7 Json綁定

4.3.8 依賴項解析

4.3.9 全局操做過濾器

4.4 ASP.NET MVC 4 概述

4.4.1 ASP.NET Web API

4.4.2 加強的默認項目模板

4.4.3 使用jQuery Mobile的移動項目模板

4.4.4 顯示模式

4.4.5 捆綁和微小框架

4.4.6 包含開源庫

4.4.7 其餘功能

4.4.8 開源發佈

4.5 ASP.NET MVC 5 概述

4.5.1 One ASP.NET

4.5.2 新的Web項目體驗

4.5.3 ASP.NET Identity

4.5.4 Bootstrap 模板

4.5.5 特性路由

4.5.6 ASP.NET基架

4.5.7 身份驗證過濾器

4.5.8 過濾器重寫

5. 結尾

▁▃▅　ASP.NET MVC 1-5 各版本特色　▅▃▁

　　ASP.NET MVC 是一種構建Web應用程序的框架，它將通常的MVC（Model-View-Controller）模式應用於ASP.NET框架。

　　下面首先介紹ASP.NET MVC和ASP.NET之間的關係。

1. ASP.NET MVC如何適應ASP.NET

　　在2002年ASP.NET 1.0首次發佈時，人們很容易將ASP.NET和Web Forms當作同一事物。儘管當時ASP.NET已經支持兩層抽象了，具體以下：

System.Web.UI：Web Forms層，由服務器控件和ViewState等組成；
System.Web：管道程序，提供基本的Web堆棧，其中包括組件模塊、處理程序和HTTP堆棧等。

　　應用ASP.NET開發的主流方法囊括了整個Web Forms堆棧 —— 利用拖放服務器控件，有用的狀態（semi-magical statefulness）來處理後臺的復瑣事務（但這樣具備常常混淆頁面生命週期，生成不太理想的HTML頁面等缺點）。

　　然而，老是會有發生下面所屬狀況的可能性，即經過使用處理器、組件模塊和其餘手寫代碼來直接響應HTTP請求，按照想要的方式構建Web框架，設計出精彩的HTML頁面。

　　雖然，能夠這麼作，可是實現起來很是困難，這並非由於普遍的計算機科學世界中缺少設計模式，而是由於缺少一種內置的模式支持這樣的實現。

　　在2007年ASP.NET MVC宣佈開發之時，MVC模式已成爲構建Web框架最流行的方式之一。

2. MVC模式簡介

　　MVC成爲計算機科學領域重要的構建模式已有多年曆史。

　　1979年，它最初被命名爲事物-模型-視圖-控制器（Thing-Model-View-Controller），後來簡化成了模型-視圖-控制器（Model-View-Controller）。

　　在分離應用程序內部的關注點方面（例如，從顯示邏輯中分離出數據訪問邏輯）MVC是一種強大而簡潔的方式，尤爲適合應用在Web應用程序總。

　　雖然關注點的顯式分離在必定程度上增長了應用程序設計的複雜性，可是整體來講，MVC帶來的利大於弊。

　　自從引入以來，MVC已經在數十種框架中獲得應用，在Java和C++語言中，在Mac和Windows操做系統中以及在不少架構內部都用到了MVC。

　　MVC將應用程序的用戶界面（User Interface，UI）氛圍了三個主要部分：

模型：一組類，描述了要處理的數據以及修改和操做數據的業務規則；
視圖：定義應用程序用戶界面的顯示方式；
控制器：一組類，用於處理來自用戶、整個應用程序流以及特定應用程序邏輯的通訊。

MVC做爲用戶界面模式

　　注意這裏的MVC指的是一種用戶界面模式。

　　MVC模式是處理用戶交互的一種解決方案，它並非應用程序關注的其餘問題，例如數據訪問、服務交互等。

　　時刻牢記：MVC是一種有用的模式，可是可能只是在開發應用程序時用到的許多模式之一。

3. MVC在Web框架中的應用

　　MVC模式常常應用於Web程序設計中。在ASP.NET MVC中，MVC三個主要部分的定義大體以下：

模型：模型是描述程序設計人員感興趣問題域的一些類，這些類一般封裝存儲在數據庫總的數據，以及操做這些數據和執行特定域業務邏輯的代碼。
在ASP.NET MVC中，模型就像是一個使用了某種工具的數據訪問層（Data Access Layer），這種工具包括實體框架（Entity Framework）或者與包含特定域邏輯自定義代碼組合在一塊兒的NHibernate。
視圖：一個動態生成HTML頁面的模板，後面再詳細介紹，本篇先不扯別的了。
控制器：一個協調視圖和模型之間關係的特殊類。它響應用戶輸入，與模型進行對話，並決定呈現哪一個視圖（若是存在的話）。
在ASP.NET MVC中，這個類文件一般之後綴名Controller表示。

注意：

　　MVC是一種高級架構模式，它的使用取決於具體的應用環境。ASP.NET MVC的上下文是問題域（一個無狀態的Web環境）和宿主系統（ASP.NET）。

　　ASP.NET MVC以來的許多核心策略，與其餘MVC平臺所使用的策略相同，再加上它提供的編譯和託管代碼的好處，以及利用.NET語言的新特性，好比Lambda表達式、動態和匿名類型，使其成爲強大的開發框架。

　　不過，本質上，ASP.NET採用了大部分基於MVC的Web框架所使用的一些基本原則：

約定優於配置（Convention over Configuration）

不重複（又名DRY原則）

儘可能保持可插拔性（Pluggability）

儘可能爲開發人員提供幫助，但必要時容許開發人員自由發揮

4. ASP.NET MVC5 的發展歷程

　　自2009年3月，ASP.NET MVC 1 發佈起，在短短几年的時間裏，ASP.NET MVC已經發布了5個主要版本，期間還有一些臨時版本。爲更好地理解ASP.NET MVC，首先知道ASP.NET MVC的發展歷程是很重要的。

　　下面我把我收集的ASP.NET MVC從1到5的各個版本整理一下都貼出來了：

4.1 ASP.NET MVC 1 概述

　　2007年2月，Microsoft公司的Scott Guthrie（ScottGu）飛往美國東海岸參加會議。在旅途中，他草擬編寫了ASP.NET MVC的內核程序。這是一個只有幾百行代碼的簡單應用程序，但它卻給大部分追隨Microsoft公司的Web開發人員帶來了美好前景。

　　聽說，2007年10月，在華盛頓州雷德蒙市舉行的Austin ALT.NET會議上，ScottGu告訴一些開發者說「我在飛機上寫了這個好東西」，並詢問他們是否看到需求以及對該應用程序的見解。在此舉一炮打響。

　　事實上，許多人都參與了該應用程序原型的設計，並把代碼命名爲Scalene。

　　Eilon Lipton於2007年9月把第一份原型電郵給他的團隊，並和ScottGu在原型、代碼、想法上屢次思考，反覆斟酌。

　　即便在官方發佈以前，ASP.NET MVC也並不符合Microsoft產品的標準，這一點是很清楚的。ASP.NET MVC的開發週期是高度交互的，在官方版本發佈以前已有9個預覽版本，他們都進行了單元測試，並在開源許可下發布了代碼。

　　全部這些都突出了一個哲理：在整個研發過程當中藥高度重視團隊的寫做交互。最終結果是在ASP.NET MVC 1 的官方版本發佈時（包含代碼和單元測試），已經被那些將一直使用它的開發者屢次使用和審查。

　　ASP.NET MVC 1 於2009年3月13日正式發佈。

4.2 ASP.NET MVC 2 概述

　　與ASP.NET MVC1發佈時隔一年，ASP.NET MVC2於2010年3月發佈。ASP.NET MVC2的部分主要特色以下：

帶有自定義模板的UI輔助程序
在客戶端和服務器端基於特性的模型驗證
強類型HTML輔助程序
改善的Visual Studio開發工具

　　根據應用ASP.NET MVC1開發各類應用程序開發人員的反饋意見，ASP.NET MVC2中加強了許多API功能以加強其「親和」性，好比：

支持將大型應用程序劃分爲域
支持異步控制器
使用HTML.RenderAction支持渲染網頁或網站的某一部分
許多新的輔助函數、使用工具和API加強

　　ASP.NET MVC2發佈的一個重要先例是不多有重大改動，這是ASP.NET MVC結構化設計的一個證實，這樣就能夠實如今核心不變的狀況下進行大量的擴展。

4.3 ASP.NET MVC 3 概述

　　在Web Matrix發佈的推進下，ASP.NET MVC 3 於ASP.NET MVC 2 發佈以後的第10個月退出。ASP.NET MVC 3 的主要特徵以下：

支持Razor試圖引擎
支持.NET 4 數據註解
改進了模型驗證
提供更強的控制和更大的靈活性，支持依賴項解析（Dependency Resolution）和全局操做過濾器
豐富的Javascript支持，其中包括非侵入式Javascript、jQuery驗證和JSON綁定
支持NuGet，能夠用來發布軟件，管理整個平臺的依賴

　　因爲這些ASP.NET MVC 3 的特性都是最近添加的，而且很是重要，所以這裏將對其作詳細介紹。

注意：

　　擁有MVC經驗的開發人員很是關心新版本中作出的更新，這裏的功能總結就是爲這些朋友準備的。

　　若是之前沒有使用過ASP.NET MVC，也沒必要擔憂，這些特性目前還可有可無，後面咱們會慢慢闡述他們，這裏您能夠簡要了解大概，看完後面的文章以後，再回頭研究這些更新的功能點等。

4.3.1 Razor視圖引擎

　　自10餘年前ASP.NET 1.0發佈以來，Razor是在渲染HTML方面的第一個重大更新。在ASP.NET MVC1和ASP.NET MVC2中默認使用的視圖引擎廣泛稱爲Web Forms視圖引擎（Web Forms View Engine），由於他和Web Forms使用了一樣的Aspx/Ascx/Master文件和語法。

　　可是它的設計目標是支持在圖形編輯器中的編輯控件。

　　下面是在Web Forms頁面中這種語法的一個示例：

ASP.NET Web Forms 示例代碼

　　Razor被專門設計成視圖引擎的語法，它有一個主要的做用：集中生成HTML代碼模板。下面展現如何應用Razor生成一樣的標記：

ASP.NET MVC Razor 示例代碼

　　Razor語法易於輸入、易於閱讀。Razor不像WebForms視圖引擎安陽具備相似於XML的繁雜語法規則。

　　前面已經討論了使用Razor語法的不一樣感覺，爲了用較爲量化的用於表達，下面討論Razor語法的設計目標：

簡潔、富有表現力和靈活性：Razor在「HTML標記生成模板」方面具備很是簡潔的語法，這不只能夠最大限度的減小代碼量，並且能夠容易的表達意圖。例如上面Razor代碼的循環就能夠發現這一點。
不是新語言：Razor語法很是直觀的支持現有的.NET編碼技術。Scott Hanselman在談及他學習Razor的經驗時，很好的總結了這一亮點：

」我一直在苦苦尋找Razor的語法規則，知道有人告訴我不要再想了，直接輸入「@」符號就能夠開始編寫代碼了，我才意識到原來Razor本無規則。「
容易學習：因爲Razor不是一門新的編程語言，所以學習Razor很是容易。若是熟悉HTML語言和.NET技術，那麼當須要編寫.NET代碼時，輸入@符號後輸入.NET代碼就能夠了。
支持全部文本編輯器：因爲Razor是輕量級並注重於HTML的語言，所以能夠自由的選擇編輯器，雖然Visual Studio的語法關鍵詞高亮顯示和只能感知功能很是牛掰，可是Razor足夠簡單，可以使用任何文本編輯器進行編輯。
強大的只能感知功能：儘管Razor能夠不適用只能感知功能進行工做，可是隻能感知功能對於查看一些事物（例如查看對象的屬性）仍是很方便的。所以，Razor在Visual Studio中提供了強大的只能感知功能，如圖：

4.3.2 驗證的改善

　　驗證是構建Web應用程序的一個重要組成部分，可是他歷來不是一項有趣的工做。在確保驗證正確的狀況下，通常老是但願用戶儘量少的時間編寫驗證碼。

　　ASP.NET MVC 2 的特性驅動驗證系統經過使用聲明式代碼替代原來重複的命令式代碼，減小了這一過程當中的不少麻煩。然而，這隻支持少數的高級驗證方案。所以在大多數狀況下仍不得不編寫大量的代碼。

　　ASP.NET MVC 3將驗證系統擴展到支持可能碰見的大部分狀況。

　　關於驗證，我們後面會單獨拿出來講。

4.3.3 支持.NET 4數據註解

　　由於ASP.NET MVC 2 編譯不兼容.NET 3.5框架，因此他不支持任何.NET 4 框架數據註解加強的功能。

　　因爲.NET 4 框架的支持，ASP.NET MVC 3 採用了一些新的且很是有用的驗證功能。如：

儘管在.NET 4框架標準中System.ComponentModel.DataAnnotations的Display特性能夠本地化，可是ASP.NET MVC2的DisplayName特性是沒法本地化的；
.NET 4框架加強了ValidationAttribute特性，以便更好地與整個模型驗證上下文協同工做，這極大地簡化了一些操做，好比驗證器，他比較或以其它方式引用兩個模型屬性。

4.3.4 經過改進模型驗證簡化驗證

　　ASP.NET MVC 3 對.NET 4 框架中IValidatableObject接口的支持值得讚美。這樣就能夠經過在模型類中實現這個接口以及相應的Validate方法，以任何想象到的方式擴展模型驗證，如：

自定義擴展模型驗證示例代碼

4.3.5 非侵入式Javascript

　　非侵入式Javascript是通常術語，他表達了一個哲理：相似於術語」表述性的狀態轉移（Representational State Transfer，REST）「。

　　直觀描述就是非侵入式Javascript不在頁面元素中混雜Javascript代碼。

　　例如，非侵入式Javascript連接頁面元素是經過元素的ID或類，這些類一般基於其餘特性的呈現（如HTML5的data-特性），而不是經過事件特性（如onclick/onsubmit/...）。

　　當把HTML之當作一個文檔時，非侵入式Javascript具備很大的意義。文檔應該有語義意義，全部這些像標籤和元素特性等，都應該有一個精確的含義。爲了促進交互而讓Javascript遍及整個頁面是不利於文檔內容的。

　　ASP.NET MVC 3 採用兩種方式支持非侵入式Javascript，分別是：

Ajax輔助類（如Ajax.ActionLink和Ajax.BeginForm）結合利用擴展的特性（data-特性）和jQuery技術爲Form標籤提供簡潔的標記。
Ajax驗證再也不將驗證規則以一塊Json數據發出（由於Json數據有時會很大），而是應用data-特性發出。
儘管從技術上考慮ASP.NET MVC 2 的驗證系統至關不侵入，可是ASP.NET MVC3系統更加不侵入 —— 標記更加輕量化，data-特性的使用讓應用jQuery和其餘Javascript庫驗證信息的利用和重用更加簡單。

4.3.6 jQuery驗證

　　ASP.NET MVC 2 支持jQuery，，而使用Microsoft Ajax進行驗證。

　　ASP.NET MVC 3 經過將驗證支持轉換到流行的jQuery驗證插件上運行，完成了爲Ajax支持使用jQuery的過渡。

　　非侵入式Javascript和使用標準插件系統的jQuery驗證的結合，讓驗證及其靈活。同時還能夠得益於強大的jQuery社區裏更豐富的插件。

　　目前ASP.NET MVC 3 項目中，客戶端驗證默認是打開的，而且能夠經過時會用web.config設置或在global.asax中編碼，讓它在整個站點中啓用。

4.3.7 Json綁定

　　ASP.NET MVC 3 經過新的JsonValueProviderFactory支持Json（Javascript Object Notation）綁定，這樣可讓方法接收和綁定Json格式的數據。

　　這一點在高級的Ajax應用中很是有用，例如客戶端元素須要和接收到的數據綁定。

4.3.8 依賴項解析

　　ASP.NET MVC 3引入了一個全新的概念，稱爲依賴解析器（dependency resolver），從而大大簡化了在應用程序中依賴注入的使用。

　　這使分離應用程序組件更加容易，從而使組件更容易配置和測試。

　　下面列舉的方案已經添加了對依賴解析器的支持：

控制器（註冊和注入控制器工廠，注入控制器）
視圖（註冊和注入視圖引擎，向頁面注入依賴關係）
操做過濾器（定位和注入過濾器）
模型綁定器（註冊和注入）
模型驗證提供器（註冊和注入）
模型元數據提供器（註冊和注入）
值提供器（註冊和注入）

　　有關詳細的，後面咱們會慢慢講到，一時半會還不須要關心這玩意兒。

4.3.9 全局操做過濾器

　　ASP.NET MVC 2 的操做過濾器能夠提供一段執行代碼的鉤子（hook），使該段代碼能夠在一個方法執行以前或以後運行。

　　這個功能能夠經過自定義特性實現，自定義的特性能夠應用於控制器的一些操做或者整個控制器。ASP.NET MVC 2 就帶有一些過濾器，例如Authorize特性。

　　ASP.NET MVC 3 運用適用於程序中全部方法的全局操做過濾器擴展了這個功能，這對於處理應用程序基礎結構的問題，像錯誤處理和日誌記錄尤爲有用。

4.4 ASP.NET MVC 4 概述

　　ASP.NET MVC 4 創建在一個至關成熟的基礎上，可以把重點放在一些高級應用上，主要功能包括：

ASP.NET Web API
加強了默認的項目模板
添加使用jQuery Mobile的手機項目模板
支持顯示模式（Display Modes）
支持異步控制器的任務
捆綁和微小（minification）

4.4.1 ASP.NET Web API

　　設計ASP.NET MVC的目的是用來建立網站，所以，整個平臺的設計目標很明確，響應瀏覽器的請求，並返回HTML。

　　然而，ASP.NET MVC是控制到字節的響應變得很是容易，並且MVC模式在建立服務層時很是有用。ASP.NET開發人員發現，使用MVC能夠建立Web服務，這些服務能夠返回XML、Json或其餘格式的數據，而且比使用其餘服務框架（如WCF或編寫原始HTTP處理程序）更容易。

　　儘管如此，它仍存在一些不足之處，好比咱們須要使用網站框架來傳遞服務。但整體而言，MVC要優於其餘框架。

　　ASP.NET MVC 4 引入了一個好的解決方案：ASP.NET Web API（簡稱Web API）。它是一個提供了ASP.NET MVC開發風格的框架，但它專門用來編寫HTTP服務。該框架包括在HTTP服務域修改一些ASP.NET MVC概念，並提供一些新的面向服務的功能。

　　下面是一些相似MVC的Web API功能，他們只適用於HTTP服務域：

路由：ASP.NET Web API使用一樣的路由系統，將URL映射到控制器操做。它按照約定將HTTP動詞映射到操做，從而實現將路由融入HTTP服務上下文，這樣既可使代碼更加易於閱讀，同時也鼓勵了RESTful服務的設計。
模型綁定和驗證：和MVC簡化映射輸入值（表單數據）到對象屬性的過程同樣，Web API自動把HTTP請求的數據映射到對象模型的屬性中。綁定系統具備良好的擴展性，而且和咱們在MVC模型綁定中同樣，他也包括基於特性的驗證。
過濾器：MVC使用過濾器以便經過特性向指定操做添加行爲。例如，向某個MVC操做中添加[Authorize]特性。此外，也能夠根據須要自定義過濾器。
基架：在添加MVC控制器的時候，咱們能夠選擇搭建一個基於某個模型類的實體框架。
簡易的單元測試：這一點和MVC很像，Web API簡歷在依賴注入和避免全局狀態使用的概念智商。

　　除此以外，Web API專門爲HTTP服務的開發，還添加了一些新的概念和功能：

HTTP編程模型：爲了更好地處理HTTP請求和響應，Web API開發經驗獲得優化。提供了一個強類型的HTTP對象模型、HTTP狀態碼和容易訪問的headers等。
基於HTTP動詞的動做調度：MVC根據操做方法的名稱來調用，而Web API則根據HTTP動詞自動調度操做方法。例如，一個GET請求會被自動調度到一個帶有[HttpGET]特性的操做中。
內容協商：HTTP已經長期支持內容協商系統，在這些系統中，瀏覽器（和其餘HTTP客戶端）給出他們響應格式優先級，服務器用它支持的首選個事做出相應。這樣咱們的控制器就能夠提供XML、Json和其餘格式的數據來響應客戶端最想要的格式。這樣就能夠爲新數據格式提供支持，而不須要修改控制器的代碼。
基於代碼的配置：服務配置是複雜的。WCF採用冗長複雜的配置文件來完成配置，與其不一樣的是，Web API徹底經過代碼配置。

　　雖然ASP.NET Web API包含在ASP.NET MVC4中，但它能夠單獨使用。事實上，它與ASP.NET不存在任何依賴關係，而且能夠自託管 —— 也就是說，獨立於ASP.NET和IIS。

　　這意味着Web API能夠運行在任何.NET應用程序中，能夠是一個Windows服務，甚至是一個簡單的控制檯應用程序。

　　有關Web API詳細介紹，咱後面再單獨拿出來講。

4.4.2 加強的默認項目模板

　　指導ASP.NET MVC 3，ASP.NET MVC 1項目默認模板的可視化設計基本保持不變，當建立一個新的ASP.NET MVC 3 項目，並運行它時，界面是藍色背景和一個白色的內容區域，如圖1所示：

　　　　　　　圖1 - ASP.NET MVC 3 應用程序啓動效果

　　在ASP.NET MVC 4中，默認模板的HTML和CSS都進行了從新設計，一個新的ASP.NET MVC 4 應用程序如圖2所示：

　　　　　　　　　　圖2 - ASP.NET MVC 4 應用程序啓動效果（登陸頁面）

　　除了擁有現代的設計以外，新建模板經過自適應佈局也支持移動瀏覽器。

　　自適應佈局是一項設計流動網頁佈局的技術，他會經過CSS媒體查詢來響應不一樣的屏幕尺寸。

　　當低於850px寬度的終端設備（如手機或平板電腦）訪問站點時，CSS會由於小表單的因素，自動從新配置優化，如圖3，Google Chrome的移動仿真器查看的效果：

　　　　　　　　　　　　圖3 - 移動設備瀏覽頁面會自適應響應

　　儘管網站值得有用自定義的設計，可是使用現代的標記和CSS設置ASP.NET MVC 4項目中的底層HTML和CSS是很是棒的，由於他們可以很好的響應不斷增加的移動瀏覽器的使用率。

4.4.3 使用jQuery Mobile的移動項目模板

　　若是要建立只有移動瀏覽器訪問的網站，能夠利用新的Mobile Project模板。

　　該模板能夠預先配置站點一邊使用流行的jQuery Mobile庫，該庫不但可以很好的適用於移動設備，並且還提供了美觀樣式，如上例圖3所示。

　　jQuery Mobile還有話了觸摸功能，支持Ajax導航和移動設備的功能。

4.4.4 顯示模式

　　顯示模式根據瀏覽器發出的請求，使用約定的方法來選擇不一樣的視圖。

　　當瀏覽器的用戶代理只是一個已知的移動設備時，默認的視圖引擎首先查找名稱以Mobile.cshtml結尾的視圖。

　　例如，若是網站項目中有一個通用視圖和一個移動視圖，他們的名稱分別是Index.cshtml和Index.Mobile.cshtml，那麼當在移動瀏覽器網站訪問到該頁面時，MVC4將自動使用移動視圖。

　　此外，還能夠根據自定義標準，註冊自定義設備模式 —— 所要作的就是編寫一行代碼。

　　例如，如今要註冊一個WinPhone設備模式，用以WinPhone.cshtml結束的視圖響應Windows Phone設備，咱們只須要在Global.asax文件的Application_Start方法中寫入以下代碼：

1             DisplayModeProvider.Instance.Modes.Insert(0, new DefaultDisplayMode("WinPhone")
2             {
3                 ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf("Windows Phone OS", StringComparison.OrdinalIgnoreCase) >= 0)
4             });

4.4.5 捆綁和微小框架

　　ASP.NET 4支持的捆綁和微小框架與ASP.NET 4.5中包含的框架相同。該框架經過合併腳本引用能夠吧若干個請求合併爲一個請求，從而減小發送到站點的請求數量。

　　與此同時，它採用各類技術來壓縮請求大小，好比縮短變量名、刪除空格和註釋等。他也很好地適用於CSS，能夠吧若干CSS請求打包成一個請求，並壓縮CSS請求的大小，使其用最少的字節，產生等價的規則，也採用高級技術（如語義分析）來摺疊CSS選擇器。

　　捆綁系統時高度配置的，咱們能夠包含特定腳本的自定義捆綁，並用單一的URL來引用這些捆綁。當使用Internet模板建立新的MVC4應用程序時，咱們經過引用/App_Start/BundleConfig.cs中列出的默認捆綁，能夠看到一些例子。

　　使用捆綁和微小系統的一個不錯的意外收穫是，咱們能夠從視圖代碼中刪除文件引用。這樣咱們就能夠在不升級視圖或佈局的狀況下，添加或升級腳本庫和那些擁有不一樣文件名成的CSS文件，由於引用的腳本或CSS綁定而不是單獨文件。

　　例如，MVC Internet應用程序模板就包含一個不依賴版本號的jQuery綁定：

1 bundles.Add(new ScriptBundle("~/bundles/jquery").Include("~/Scripts/jquery-{version}.js"));

　　而後在站點中（~/Views/Shared/_Layout.cshtml），經過綁定URL來引用它，代碼以下：

1 @Scripts.Render("~/bundles/jquery")

　　因爲這些引用不用綁定到jQuery版本號，所以綁定和微小系統將自動得到更新的jQuery庫（經過NuGet或手動），而不須要修改任何代碼。

4.4.6 包含開源庫

　　長久以來，MVC項目模板包含頂級的開源庫，例如jQuery和Modernizr。自MVC3起，這些庫經過NuGet包含，這使庫的更新和以來管理變得極其簡單。

　　除此以外，MVC4項目模板還引入了一些新庫：

Json.NET：Json.NET是一個操做Javascript對象符號中信息的.NET庫。它做爲Web API的一部分包含在MVC4中，從而能夠實現將數據序列化爲Json格式，序列化過程當中考慮到了數據契約、匿名類型、動態類型、日期、時間戳、對象引用保存、縮進、駝峯命名法以及許多其餘有用的序列化功能。此外，還能夠利用Json.NET的其餘功能，好比LINQ to JSON和JSON到XML的自動轉換。
DotNetOpenAuth：MVC使用DotNetOpenAuth來支持基於OpenID-和OAuth-的登陸，這種登陸須要使用第三方身份提供器。Account控制器經過設置能夠很容易地添加對Facebook、Microsoft、Google和Twitter的支持；然而，因爲這些登陸創建在OpenID和OAuth智商，所以咱們能夠很容易地插入其餘提供器。儘管能夠直接使用DotNetOpenAuth類，但MVC4也提供了一個OAuthWebSecurity來簡化其通常用法。

4.4.7 其餘功能

　　除了上面列出的功能以外，MVC4還包括許多其餘功能。完整的功能列表在發佈說明裏，若是有興趣可查閱http://www.asp.net/whitepapers/mvc4-release-notes。

　　下面列出了最感興趣的且不與前面任何主題重複的三項功能：

配置邏輯轉移到App_Start：儘管新能能極其精彩，可是經過代碼進行的額外功能邏輯配置正開始集中到Global.asax中的Application_Start方法。慶幸的是，這些配置已經轉移到了App_Start目錄下的靜態類中：
- AuthConfig.cs：用來配置安全設置，其中包括站點的OAuth登陸；
- BundleConfig.cs：用來註冊捆綁和微小系統使用的捆綁。裏面默認添加一些捆綁，包括jQuery、jQueryUI、jQuery驗證、Modernizr和默認的CSS引用；
- FilterConfig.cs：顧名思義，它是用來註冊全局MVC過濾器。文件中儘管只默認註冊一個過濾器HandleErrorAttribute，但這裏絕對是註冊其餘過濾器的好地方；
- RouteConfig.cs：存放MVC配置語句、路由配置的鼻祖。咱們稍後會詳細介紹MVC中的路由機制。
- WebApiConfig.cs：用來註冊Web API路由，以及設置任何其餘Web API配置設置。
空的MVC項目模板：儘管自MVC2以來，ASP.NET MVC都好含有Empty項目模板，但該模板不真正爲空：它仍然包含着目錄結構、一個CSS文件以及許多Javascript文件。在你們的請求下，該模板改名爲Basic，而且新的Empty項目模板真正爲空。
在任何位置添加控制器：在此以前，Visual Studio的「添加控制器」菜單項只有在Controllers文件夾上單擊右鍵纔會出現。然而，使用Controllers文件夾純粹是爲了組織結構。
MVC會將任何實現了IController接口的類當作控制器，而無論該類在應用程序的那個位置。
所以MVC4 Visual Studio工具更正了這一問題，使得「添加控制器」菜單項能夠在MVC項目的任何文件夾上顯示。
這樣就能夠根據本身的須要組織控制器的位置，好比分離邏輯組或分離MVC和Web API控制器。

MVC4測試版包含了一些有趣的實驗性功能，可是這些功能未包含在MVC4的發佈版中，這些功能後面計劃做爲帶外版發佈：

單頁面應用程序

　　單頁面應用程序是一個新的項目模板，它使用Javascript和Web API來構建集中於客戶端交互的單頁面應用程序。這種Web應用程序具備很是好的互動性和有效性，像Microsoft Outlook Web Access和Gmail等，但弊端是，這種應用程序構建起來很是困難。單頁面應用程序包括：

一組Javascript庫，用來與本地緩存數據進行交互

其餘Web API組件，用於支持操做單元和DAL

支持基架的MVC項目模板，用來捆綁組件

　　

　　單頁面應用程序的預覽版本引發了開發人員濃厚的興趣，開發人員也及時地給予了反饋。遺憾的是，開發團隊不能再MVC4發佈以前完成開發，而不得已從MVC4 RC中刪除。

Recipes

　　Recipes能夠很容易地經過NuGet包更新Visual Studio工具。開發團隊最初想用來擴展MVC工具，好比「添加Area」、「添加控制器」和「添加視圖」對話框等。

　　Phil展現了視圖移動器（View Mobilizer）的樣例，Recipes能夠經過一個簡單的複選框來建立現有視圖的移動版本。

　　然而，開發團隊意識到Recipes有許多潛在的功能，而不只是擴展MVC工具。各式各樣的NuGet包能夠受益於Visual Studio工具，由於它提供了簡化的配置、自動化和設計器等。

　　所以，在MVC4測試版以後的版本中刪除了Recipes，可是它會包含在NuGet發佈版本中。

4.4.8 開源發佈

　　從最第一版本開始，ASP.NET MVC一直都遵循開源許可條例，但它只是開發的源代碼而不是一個徹底開源的項目。咱們能夠閱讀源代碼、能夠修改源代碼、甚至能夠發佈修改後的源碼，可是咱們不能他本身的嗲嗎貢獻到官方的MVC代碼庫。

　　2012年5月修改了ASP.NET Web Stack開原公告。這一公告標誌着，ASP.NET MVC、ASP.NET Web Pages（包括Razor試圖引擎）和ASP.NET Web API由開源許可代碼正式過渡到了徹底的開源項目。

　　對這些項目的全部代碼修改和問題跟蹤都能顧反饋到公共代碼中，而且在開發團隊贊成修改生效的狀況下，這些項目接收社會的代碼貢獻（即pull請求）。

　　因爲該項目已經成爲開源項目，所以即便是在很短期內，官方源碼也能接收一些bug修復和功能加強，而且接收的這些更新將和MVC4一塊兒發佈。

　　ASP.NET團隊會審查和測試外部提交的代碼，而且當項目發佈時，與前面的ASP.NET MVC版本同樣，由Microsoft支持。

　　即便咱們不打算貢獻任何源碼，公共代碼庫也在可視化方面作了重大改變。在過去，須要等待臨時版本以瞭解開發團隊的最新工做進展，咱們能夠查看新簽入的源碼（網址：http://aspnetwebstack.codeplex.com/SourceControl），甚至在夜間運行新發布的代碼以測試添加的新功能。

4.5 ASP.NET MVC 5 概述

　　2013年10月，ASP.NET MVC 5與Visual Studio 2013一塊兒發佈。這個版本的關注點是「One ASP.NET」計劃（稍後介紹），以及對整個ASP.NET框架所作的核心加強。

　　下面列出了一些主要特性：

One ASP.NET
新的Web項目體驗
ASP.NET Identity
Bootstrap 模板
特性路由
ASP.NET基架
身份驗證過濾器
過濾器重寫

4.5.1 One ASP.NET

　　有不少的選項是好事。Web應用程序千差萬別，而Web工具和平臺也不是有了一種就能夠應對全部狀況。

　　可是另外一面，一些選項會讓咱們束縛手腳。正如「魚和熊掌不可兼得」，若是選擇同樣東西意味着放棄另外一樣東西，那麼咱們不但願被迫必須選擇他。

　　這一點特別適用於開始建立項目時的選項：咱們剛剛開始建立項目，怎麼知道一年之後這個項目須要什麼！

　　在以前的MVC版本中，每次建立項目的時候都面臨着選擇：建立一個MVC應用程序、Web Forms應用程序或其餘項目類型。以後，實際上咱們就被限制住了。

　　在某種程度上，能夠吧Web Forms添加到一個MVC應用程序中，可是把MVC添加到Web Forms應用程序中是很困難的。

　　MVC應用程序在csproj文件中隱藏了一種特殊的項目類型GUID，當嘗試吧MVC添加到Web Forms應用程序時，這只是必須作的幾個神祕修改之一。

　　在MVC5中，狀況發生了變化，由於如今只有一種ASP.NET項目類型，如圖4所示：

　　　　　　　　　　　　　圖4 - ASP.NET MVC 5 項目模板

　　在Visual Studio 2013中建立新的Web應用程序時，沒有複雜的選項，只有Web應用程序。不僅是在一開始建立ASP.NET項目時才支持這麼作：在不斷開發的過程當中，能夠添加對其餘框架的支持，由於工具和特性都是做爲NuGet包提供的，

　　例如，若是開發過程當中改變了想法，就可使用ASP.NET基架向任何現有的ASP.NET應用程序添加MVC。

4.5.2 新的Web項目體驗

　　做爲新的One ASP.NET體驗的一部分，Visual Studio 2013中建立新的MVC應用程序的對話框已被合併和簡化（如上述圖4），下篇我們在一步步建立一個項目瞅瞅裏面啥樣的。

4.5.3 ASP.NET Identity

　　MVC5完全重寫了成員和身份驗證系統，使其成爲新的ASP.NET Identity系統的一部分。這個新系統拜託了原來的ASP.NET成員系統的陳舊侷限，並讓MVC4的Simple Membership系統變得更加成熟，可配置性更好。

　　下面列出了ASP.NET Identity的一些主要新特性：

One ASP.NET Identity系統：爲了支持前面介紹的One ASP.NET這個關注點，新的ASP.NET Identity被設計爲可在整個ASP.NET家族中使用（包括MVC、Web Forms、Web Pages、Web API、SignalR，以及使用其中任何技術組合建立的混合應用程序）。
控制用戶資料數據：雖然ASP.NET的成員系統常被用於存儲關於用戶的額外的、自定義的信息，可是使用起來越很困難。ASP.NET Identity使得存儲額外的用戶信息（如帳號、社交媒體信息和聯繫地址）很容易，只須要在表明用戶的模型類中添加屬性便可。
控制優於持久化：默認狀況下，全部用戶信息都是用Entity Framework Code First存儲，因此能夠得到咱們在使用Entity Framework Code First的時候已經習慣了的簡單性和控制。
可是，也能夠插入其餘任何咱們但願使用的持久化機制，包括其餘ORM、數據庫、自定義的Web服務等。
可測試性：ASP.NET Identity API是使用接口設計的，因此容許爲用戶相關的應用程序代碼編寫單元測試。
基於聲明：雖然ASP.NET Identity仍然支持用戶角色，可是也支持基於聲明的身份驗證。
聲明的表達力比角色強許多，因此給咱們提供了強大的能力和靈活性。
角色成員關係是一個簡單的布爾值（是/不是管理員身份）。而用戶聲明能夠包含豐富的信息，好比用戶的成員級別或身份細節等。
登陸提供器：ASP.NET Identity並非只關注用戶名/密碼身份驗證，而是也理解用戶常常經過社交服務提供器（如Microsoft 帳戶、Facebook或Twitter）和Windows Azure Active Directory進行身份驗證。
NuGet分發：ASP.NET Identity做爲NuGet包安裝到應用程序中。這意味着能夠單獨安裝ASP.NET Idetntiy，而且經過更新一個NuGet包，就能夠把它升級到最新版本。