前面篇文章我們分別介紹用真正用於實施Model驗證的ModelValidator（《ASP.NET MVC以ModelValidator為核心的M

在前面三篇文章（《ModelValidator》、《ModelValidatorProvider》和《ModelValidatorProvider

通過前面的介紹我們知道ModelValidatorProviders的靜態只讀Providers維護著一個全局的ModelValidatorPro

對於ASP.NET MVC基於標注特性的Model驗證，很多人只知道應用在數據類型及其屬性上用於定義驗證規則和錯誤消息的ValidationAtt

DataAnnotationsModelValidator最終是通過它對應的ModelValidatorProvider，即DataAnnotat

ASP.NET MVC默認采用基於標准特性的Model驗證機制，但是只有應用在Model類型及其屬性上的ValidationAttribute才有

對於Model驗證，理想的設計應該是場景驅動的，而不是Model（類型）驅動的，也就是對於同一個Model對象，在不同的使用場景中可能具有不同的驗

Visual Studio提供的Controller創建向導默認為我們創建一個繼承自抽象類Controller的Controller類型，這樣的C

Action方法的執行具有兩種基本的形式，即同步執行和異步執行，而在ASP.NETMVC的整個體系中涉及到很多同步/異步的執行方式，雖然在前面相應

關於ASP.NET MVC對請求的處理方式（同步或者異步）涉及到的五個組件，在《上篇》中我們談了三個（MvcHandler、Controller和

看了dudu的《HttpClient + ASP.NET Web API, WCF之外的另一個選擇》一文，想起多很久之前體現ASP.NET Web

對於大部分面向最終用戶的應用來說，它們都需要具有一個可視化的UI與用戶進行交互，我們將這個UI稱為視圖（View）。在早期，我們傾向於將所有與視圖

[上篇]通過采用MVC模式，我們可以將可視化UI元素的呈現、UI處理邏輯和業務邏輯分別定義在View、Controller和Model中，但是對於

ASP.NET由於采用了管道式設計，具有很好的擴展性，而整個ASP.NET MVC應用框架就是通過擴展ASP.NET實現的。通過上面對ASP.NE

在一個ASP.NET MVC應用來說，針對HTTP請求的處理和相應定義Controller類型的某個Action方法中，每個HTTP請求的目標對象

ASP.NET MVC的URL路由系統通過注冊的路由表對HTTP請求進行解析從而得到一個用於封裝路由數據的RouteData對象，而這個過程是通過

作為Controller基類ControllerBase的Execute方法的核心在於對Action方法的執行和作為方法返回的ActionResu

表現為請求地址與目標Controller和Action的動態映射的URL路由系統並不是專屬於ASP.NET MVC，而是直接建立在ASP.NET

總的來說，我們可以通過RouteTable的靜態屬性Routes得到一個基於應用的全局路由表，通過上面的介紹我們知道這是一個類型的RouteCol

前面我們已經提到過，ASP.NET 的路由系統主要具有兩個方面的應用，其一就是通過注冊URL模板與物理文件路徑的匹配實現請求地址和物理地址的分離；