ASP

總的來說，針對目標Action方法參數的Model綁定完全由組件ModelBinder來實現，在預設情況下使用的ModelBinder類型為DefaultModelBinder，接下來我們將按照逐層深入的方式介紹實現在DefaultModelBinder的預設Model綁定機制。[原始碼從這裡下載]一、簡單類型對於旨在繫結目標Action方法參數值的Model來說，最簡單的莫過於簡單參數類型的情況。通過《初識Model中繼資料》的介紹我們知道，複雜類型和簡單類型之間的區別僅僅在於是否支援針對字串

Model的綁定體現在從當前請求提取相應的資料繫結到目標Action方法的參數。通過前面的介紹我們知道Action方法的參數通過ParameterDescriptor來描述，ParameterDescriptor的BindingInfo屬性工作表示的ParameterBindingInfo對象具有一個名為ModelBinder的組件用於完成針對當前參數的Model綁定。ModelBinder可以看成是整個Model繫結系統的核心，我們先來認識這個重要的組件。一、

ValueProviderFactory在ASP.NET Model繫結系統中，用於提供資料值的ValueProvider對象通過ValueProviderFactory來建立。在ASP.NET MVC應用編程介面中，ValueProviderFactory繼承自ValueProviderFactory類。本篇文章只要介紹基於ValueProviderFactory的ValueProvider的提供機制，以及如何通過自訂ValueProviderFactory實現我們需要的資料值的綁定方式。一、

DictionaryValueProviderNameValueCollectionValueProvider採用一個NameValueCollection作為資料來源，DictionnaryValueProvider的資料來源類型自然就是一個Dictionnary。NameValueCollection和Dictionnary都是一個索引值對的集合，它們之間的不同之處在NameValueCollection運行元素具有相同的Key，Dictionnary卻要求元素的Key具有唯一性。一、Dic

NameValueCollectionValueProvider在進行Model綁定過程中，需要根據基於Action方法參數的綁定上下文從請求資料中提取相應的資料以提供相應的資料。具體來說，Model繫結資料具有多個來源，可能來源於Post的表單或者JSON字串，或者來源於當前的路由資料，也可能來源於請求地址的插敘字串。ASP.NET

ASP.NET MVC通過Model驗證協助我們很容易的實現對資料的驗證，在預設的情況下，基於ValidationAttribute的聲明是驗證被使用，我們只需要將相應的ValidationAttribute應用到Model的類型或者屬性上即可。對於自訂驗證，我們也只需要定義相應的Validation就可以了，不過服務端驗證比較簡單，而用戶端驗證就要稍微複雜一些，本文提供一個簡單的執行個體說明在ASP.NET

在簡單瞭解了Unobtrusive JavaScript形式的驗證在jQuery中的編程方式之後，我們來介紹ASP.NET

之前我們一直討論的Model驗證僅限於服務端驗證，即在Web伺服器根據相應的規則對請求資料實施驗證。如果我們能夠在用戶端（瀏覽器）對使用者輸入的資料先進行驗證，這樣會減少針對伺服器請求的頻率，從而緩解Web伺服器訪問的壓力。ASP.MVC 2.0及其之前的版本採用ASP.NET Ajax進行用戶端驗證，在ASP.NET MVC 3.0中，jQuery驗證架構被引入是我們可以採用Unobtrusive JavaScript的方式進行用戶端驗證。一、Unobtrusive

基於Web

在《ASP.NET

Razor引擎具有兩個核心的類型，一個是表示View本身的類型RazorView，另一個則是擷取和建立它的RazorViewEngine，我們將用兩篇文章對它們分別進行剖析。Razor引擎下的View通過類型RazorView表示，它與表示Web

通過.cshtml或者.vbhtml檔案定義的View能夠被執行，必須先被編譯成存在於某個程式集的類型，ASP.NET MVC採用動態編譯的方式對View檔案實施編譯。當我們在對ASP.NET MVC進行部署的時候，需要對.cshtml或者.vbhtml檔案進行打包。針對某個View的第一次訪問會觸發針對它的編譯，一個View對應著一個類型。我們可以對.cshtml或者.vbhtml進行修改，View檔案修改後的第一次訪問將會導致View的再一次編譯。和ASP.NET

在《[設計篇]》篇中我們通過對View引擎的總體介紹講述了從ViewResult的建立到View呈現的原理，為了讓讀者對View引擎及其View呈現機制具有一個深刻的認識，我們自訂一個簡單的用於呈現靜態HTML的StaticFileViewEngine。在一個通過Visual Studio的ASP.NET

在前面的四篇文章中，我們介紹了各種ActionResult以及相關的請求響應機制，但是與“View的呈現”相關的ActionResult是ViewResult。通過ViewResult的執行實現的對View的呈現比上面我們介紹的各種ActionResult要複雜得多，ASP.NET MVC內部設計了一個擴充的View引擎實現了最終的View呈現工作。[本文已經同步到《How ASP.NET MVC Works?》中]一、View引擎中的ViewASP.NET

HttpStatusCodeResult & RedirectResult/RedirectToRouteResult在本系列的最後一篇，我們來討論最後三個ActionResult：HttpStatusCodeResult、RedirectResult和RedirectToRouteResult 。第一個用於實現針對某個HTTP狀態的響應，而後兩個用於實現重新導向。至於重新導向，又分為“暫時重新導向”和“永久重新導向”，按照響應狀態，又稱&

在之前的兩篇文章（《EmptyResult &

FileResult是一個基於檔案的ActionResult，利用FileResult我們可以很容易地將從某個物理檔案的內容響應給用戶端。ASP.NET

定義在Controller中的Action方法大都返回一個ActionResult對象。ActionResult是對Action執行結果的封裝，用於最終對請求進行響應。ASP.NET MVC提供了一系列的ActionResult，它們本質上是通過怎樣的方式來響應請求的呢？這是這個系列著重討論的主題。一、ActionResult對請求的響應HTTP是一個單純的採用請求/回複訊息交換模式的網路通訊協定，Web伺服器在接收並處理來自用戶端的請求後會根據處理結果對請求予以響應。對於來自用戶端的訪問請求，

通過《執行個體篇》的實示範可以看出我們通過擴充實現的自動異常處理機制能夠 利用EntLib的EHAB根據執行的一場處理策略對某個Action方法執行過程中拋出的 異常進行處理。對於處理後的結果，則按照如下的機制對請求進行響應。[原始碼 從這裡下載]對於Ajax請求，直接建立一個用於封裝被處理後異常的資料對象，並據此建立 一個JsonResult將異常資訊回複給用戶端。對於非Ajax請求，如果當前Action方法上應用HandleErrorActionAttribute特

個人覺得異常處理對於程式員來說是最為熟悉的同時也是最難掌握的。說它熟 悉，因為僅僅就是try/catch/finally而已。說它難以掌握，則是因為很多開發人 員卻說不清楚try/catch/finally應該置於何處？什麼情況下需要對異常進行日誌 記錄？什麼情況下需要對異常進行封裝？什麼情況下需要對異常進行替換？對於 捕獲的異常，在什麼情況下需要將其再次拋出？什麼情況下則不需要？合理的異常處理應該是情境驅動的，在不同的情境下，採用的異常處理策略往