《ASP.NET MVC 5 編程實戰》 - 學習筆記

《ASP.NET MVC 5 編程實戰》

========== ========== ==========
[作者] (美) Dino Esposito
[譯者] (中) 潘麗臣
[出版] 清華大學出版社
[版次] 2015年03月 第1版
[印次] 2015年03月 第1次 印刷
[定價] 59.80元
========== ========== ==========

【前言】

Web Forms 的最常見應用場景是，你要開發專注于呈現資料并使用第三方控制元件套裝的應用程式，

ASP.NET MVC 可用于處理其他所有方面，包括客戶端單頁面應用程式的框架搭建，

ASP.NET MVC 足以成為任何一個需要物體后臺的應用程式的理想 Web 平臺，對于那些以多設備實用功能為目標的 Web 應用程式來說尤其如此，

【第01章】

(P003)

在 ASP.NET MVC 中，每個請求的結果最終都會執行某個操作 —— 根本上來說也就是特定類上的方法，操作執行的結果會與一個視圖模板一起傳遞給視圖子系統，結果和模板隨后會用于生成瀏覽器的最終回應，用戶不需要將瀏覽器指向某個頁面，他們只需要放置一個請求即可，

使用 ASP.NET MVC ，可以獲得對標記的完全控制，并能隨意用你最喜歡的 JavaScript 框架來套用樣式和注入腳本代碼，

(P004)

在軟體中，術語 URI (統一資源識別符號) 是指通過一個位置或一個名稱來參考資源，

當 URI 通過位置識別資源時，它被稱為 URL 或統一資源定位符，

當 URI 通過名稱識別資源時，它就成為一個 URN 或統一資源名稱，

(P005)

在 ASP.NET 中， HTTP 處理程式是一個實作了 IHttpHandler 介面的組件，

HTTP 處理程式可以決議出令牌中的 URL ，并使用該資訊來標識要呼叫的類和方法，

(P007)

處理請求的專門組件是控制器，控制器是一個只有方法而無狀態的類，

獨特的系統級 HTTP 處理程式負責將傳入的請求分派到一個專門的控制器類，這樣該類的實體就會執行給定的操作方法并產生回應，

URL 路由 HTTP 模塊通過查看 URL 并把它們分派到最適當的執行器來處理傳入的請求， URL 路由 HTTP 模塊取代了舊版本 ASP.NET 的 URL 重寫功能、在其核心處， URL 重寫由掛接請求、決議原始 URL 和指示 HTTP 運行時環境組成，用以處理 “可能相關卻不同” 的 URL ，

(P008)

URL 重寫確實可以將處理該請求的物理網頁與所需的 URL 進行解耦，

在 ASP.NET MVC 中， URL 路由提供了把傳入的 URL 映射到控制器類和操作方法的服務，

URL 路由模塊最初是作為 ASP.NET MVC 組件來開發的，而現在成為 ASP.NET 平臺的一個原生部分，且如前所述，它能夠同時為 ASP.NET MVC 和 ASP.NET Web Forms 應用程式提供服務，雖然是通過略微不同的 API ，

只有與預定義 URL 模式 (也稱為路由) 相匹配的請求才能享有 ASP.NET MVC 運行時，所有這類請求會被路由到一個共同的 HTTP 處理程式，該處理程式將控制器類實體化并呼叫該類中一個定義了的方法，接下來，控制器方法會進而選擇視圖組件生成實際的回應，

(P009)

在 ASP.NET MVC 中實作一個純粹的 REST 解決方案是可能的，但需要做一些額外作業，

(P010)

應用程式路由通常在 Global.asax 檔案中注冊，并在應用程式啟動時得到處理，

(P011)

RegisterRoutes 是一個在通常命名為 APP_Start (但可以隨意重命名該檔案夾) 的單獨檔案夾中所定義的 RouteConfig 類的方法，

所支持的路由必須添加到由 ASP.NET MVC 管理的路由物件的靜態集合中，該集合就是 RouteTable.Routes ，

(P012)

為確保按正確順序處理該路由，必須將它們按照從最具體到最不具體的順序羅列出來，

(P014)

默認情況下， ASP.NET 路由系統會忽略那些其 URL 可以映射到實際存在于服務器上的檔案的請求，請注意，如果服務器檔案存在，則路由系統將忽略該請求，即使請求匹配了路由，

(P015)

通過 URL 路由篩選器的任何請求都被映射到一個控制器類，通過執行類上的給定方法來進行服務，

常見的做法包括為應用程式所實作的每個重要功能配備一個控制器類，

(P017)

控制器類的撰寫可以概括為兩個簡單的步驟 : 第一，創建從 Controller 繼承 (直接或間接均可) 而來的類；第二，添加一系列的公共方法，然而，必須闡明兩個重要的細節 : 系統如何獲知控制器類要實體化，以及它如何確定要呼叫的方法，

不論如何定義 URL 模式，任何請求都必須根據控制器名稱和操作名稱來決議，這是 ASP.NET MVC 的一個支柱，如果 URL 包含了一個 {controller} 占位符，那么控制器名稱會自動從 URL 中讀取，如果 URL 包含了 {action} 占位符，那么操作名稱也將從 URL 中自動讀取，

(P020)

將特定動詞分配到給定的操作方法的能力很自然地會導致重復的方法名稱，具有相同名稱的兩種方法在控制器類中都可以被接受，只要它們接受不同的 HTTP 動詞，否則，將引發例外，因為 ASP.NET MVC 不知道如何決議一詞多義的情況，

還可以使用多個單獨的特性，每個特性用于一個 HTTP 動詞，

(P021)

容器物件通常也稱為視圖模型，可以是一對 名稱 / 值 的淺顯字典，或者是特定的視圖強型別類，

(P022)

控制器操作方法可以訪問任何通過使用 HTTP 請求而提交的輸入資料，輸入資料可以從各種來源檢索，包括表單資料、查詢字串、 Cookies 、路由值和提交檔案，

在撰寫操作方法的主體時，當然可以訪問傳給 Request 物件及其子集的任何資料，這些 Request 物件及子集包括 Form 、 Cookies 、 ServerVariables 和 QueryString ，

在 ASP.NET 中， Request.Params 字典產生于四個不同字典的組合，即 QueryString 、 Form 、 Cookies 和 ServerVariables ，也可以使用 Request 物件的 Item 索引器屬性，它會提供一樣的功能，并按一下順序在字典中搜索匹配項 : QueryString 、 Form 、 Cookies 和 ServerVariables ，

(P028)

ActionResult 類的最終目的是準備好要回傳到瀏覽器的 HttpResponse 物件，

在 ASP.NET Web Forms 中，構成 HTML 的任務是通過頁面完成的，開發人員創建 ASPX 頁面作為視圖模板和代碼隱藏類的混合容器，抓取結果的操作與實際回應的產生，這兩者在單一的運行時環境中是難以分開的，

在 ASP.NET MVC 中，產生出結果是操作方法的責任；管理回應的構成和服務則是框架的責任，而最后，構成 HTML 標記更是另一個系統組件 —— 視圖引擎 —— 的責任，

視圖引擎規定了視圖模板的語法 (比如 ASPX 、 Razor 和 Spark) ；而由開發人員決定合并到視圖的原始資料格式，

(P029)

視圖模板檔案的擴展名也取決于視圖引擎的實作，對于 ASP.NET MVC 中的兩個預定義的視圖引擎來說，如果選擇 ASPX 視圖引擎，那么擴展名為 .aspx ；如果選擇 Razor 視圖引擎，則擴展名為 .cshtml (或 .vbhtml) ，

ASP.NET MVC 非常適合實作那些會從 Ajax 背景關系的 jQuery 代碼片段中回呼的簡單 Web 服務，只需設定一個或多個操作方法，以回傳 JSON 字串而不是 HTML ，

Json 幫助器方法可以獲取一個普通的 .NET 物件，并使用內置的 JavaScriptSerializer 類將它序列化為字串，

ASP.NET MVC 會將任何從操作方法回傳的值 (數字、字串或自定義物件) 封裝成一個 ContentResult 物件，

ContentResult 物件的執行會導致瀏覽器中值的序列化，

空白回傳值實際上是被映射到了 EmptyResult 物件，而它的執行不會觸發任何操作，

(P030)

控制器的主要目的是服務于用戶界面的需要，需要執行的任何服務器端函式都要映射到一個控制器方法并從用戶界面觸發，執行完自己的任務后，控制器方法會選擇下一個視圖、封裝一些資料并指示資料的提交，

(P031)

請記住，在 ASP.NET MVC 中，解決方案建筑中的任何分層都取決于你，

【第02章】

(P033)

在 ASP.NET MVC 中，只需要處理兩種主要型別的組件，一種是控制器，它負責執行請求并為原始輸入生成原始結果，另一種是視圖引擎，它負責生成基于由控制器計算出的結果的任何預期的 HTML 回應，

可以把 ASP.NET MVC 應用程式看作是能夠服務于各種回應的組件集合，這些回應包括 HTML 、 JavaScript 、 JavaScript 物件標志 (JSON) 和純文本，

(P034)

視圖引擎是為瀏覽器實際生成 HTML 輸出的組件，視圖引擎負責為每個請求回傳 HTML ，并且它通過將視圖模板和由控制器傳遞進來的資料進行融合來準備其輸出，該模板以一種引擎專用的標記語言來表示；其資料在字典或強型別物件中進行封裝傳遞，

在 ASP.NET MVC 中，視圖引擎只是一個實作固定介面 —— IViewEngine 介面的類，每個應用程式可以有一個或多個視圖引擎，在 ASP.NET MVC 5 中，每個應用程式默認配備兩個視圖引擎，

(P035)

ViewEngines 類是跟蹤當前已安裝引擎的系統資源庫，

(P036)

最可能面臨使用 ViewEngines.Engines 的情況是當需要添加一個新的視圖引擎或卸載現有視圖引擎的時候，這需要在應用程式啟動時進行，更準確地說，是在 Global.asax 里的 Application_Start 事件中，

(P037)

控制器和視圖引擎的活動都由一個外部的管理器物件 (操作呼叫程式) 進行協調，

(P038)

控制器類上的 View 方法會將幾段資料一起封裝進一個單獨的容器 : ViewResult 類中，

視圖的名稱是控制器操作上 View 方法應該提供的引數之一，如果程式員沒有顯式定義這樣的引數，則系統會按照慣例假定視圖名稱與操作名稱相同，

(P040)

視圖引擎的呼叫會依照它們的注冊順序，并且在默認情況下， ASPX 引擎會優先于 Razor 引擎，若要修改這一順序，需要在應用程式啟動時清除引擎集合，再重新按喜歡的順序添加引擎，

(P041)

視圖無非是用來生成 HTML 內容的模板，

(P042)

在 ASP.NET MVC 中，把需要傳遞到視圖的資料在一個容器物件中進行分組，再將該容器物件作為選擇了該視圖的控制器呼叫中的引數進行傳遞，

ASP.NET MVC 使你能夠在對 View 方法的呼叫中直接傳遞容器物件，在任何情況下，都有兩個預定義的字典可用于控制器方法填充資料，它們分別是 ViewData 字典和 ViewBag 字典，

需要記住的是，在理想的情況下，視圖物件不需要自行檢索資料；它必須處理的唯一資料只是從控制器所接收的資料，

指定母版視圖是比較容易的，可以使用視圖引擎所支持的規則，也可以在從控制器中選擇下一個視圖時將母版視圖的名稱作為引數傳遞給 View 方法，

(P043)

在 ASP.NET MVC 中等同于 服務器控制元件的技術是什么？答案就是 HTML 幫助器，

HTML 幫助器就是簡單的 HTML 工廠，

HTML 幫助器的內部機制就是將文本累加到一個 StringBuilder 物件中，

(P044)

每個 HTML 幫助器均有一大堆多載來指定特性值和其他相關資訊，

一個形如 xxxFor 的幫助器與基礎版本的不同之處在于它只接受 lambda 運算式，

(P045)

默認情況下， BeginForm 會呈現一個回發到相同 URL 并隨后回發相同控制器操作的表單，

使用 BeginForm 方法的其他多載，可以指定目標控制器的名稱和操作、該操作的任意路由值、 HTML 特性，甚至可以指定是否需要表單執行 GET 或 POST 動作，

BeginRouteForm 的作用與 BeginForm 差不多，但有一點不同，它可以從任意一組路由引數開始而生成一個 URL ，換句話說， BeginRouteForm 并不局限于基于控制器名稱和操作的默認路由，

(P046)

能在表單中使用的所有 HTML 元素都有一個 HTML 幫助器來加速開發，

從功能的角度來看使用幫助器與使用普通的 HTML 之間并無差別，

擁有將驗證訊息與輸入欄位相關聯的工具，如果指定的欄位中包含錯誤，則可以使用 Html.ValidatiobnMessage 幫助器來顯示驗證資訊，該訊息可以通過幫助器的一個附加引數顯式指示出來，所有的驗證訊息之后會通過 Html.ValidationSummary 幫助器聚合與顯示出來，

(P047)

ActionLink 幫助器是 ASP.NET MVC 視圖中最常用到的一個，

通常情況下，操作鏈接需要鏈接文本、操作名稱和可選的控制器名稱，

RouteLink 幫助器的作業方式差不多相同，但它不需要指定操作，有了 RouteLink 幫助器，就可以使用任何已注冊的路由名稱來確定生成的 URL 的模式了，

若要生成基于控制器和操作資料的鏈接，則可以使用 UrlHelper 類，

UrlHelper 類有幾個方法的作用類似于 ActionLink 和 RouteLink ，它們的名稱是 Action 和 RouteUrl ，

(P048)

可以使用 Partial 或 RenderPartial 幫助器方法來插入一個部分視圖，這兩種方法都采用該部分視圖的名稱作為引數，兩者的唯一區別是 Partial 回傳一個字串，而 RenderPartial 會寫入到輸出流，并回傳空，因此，兩者的用法稍有不同，

部分視圖包含在視圖中，但會被視作完全獨立的物體，

為一個視圖引擎撰寫一個視圖而該視圖的部分視圖卻需要另一個視圖引擎的情形是完全合理的，

(P049)

有了模板化幫助器，就不會失去對用戶界面的控制了；簡言之，模型中的特性建立起一系列的規則，將你從繁重的重復勞動中解放了出來，

在 ASP.NET MVC 中，有兩個基本的模板化幫助器 : Editor 和 Display ，

ViewBag 是在被定義為動態型別的 ControllerBase 類上定義的屬性，

(P050)

lambda 運算式不支持動態成員，因此不能用于將資料傳遞到 ViewBag 字典，

Editor 幫助器的目的是讓你編輯指定值或物件、該編輯器會識別它所獲取的值的型別，并挑選量身定做的模板進行編輯，

Editor 幫助器極其擅長處理復雜型別，它通常會遍歷每一個公共屬性，并為子值建立一個標簽和編輯器，

(P051)

TagBuilder 類生成 HTML 標記的文本，從而可以通過串聯標簽而非普通的字串以構建大塊的 HTML ，

HTML 幫助器預期會回傳一個已編碼的 HTML 字串，

(P052)

所有的原生 HTML 幫助器都會被重構以回傳 MvcHtmlString ，

MvcHtmlString 型別是對包含 HTML 內容的字串的一個智能封裝，它公開了 IHtmlString 介面，

IHtmlString 的目的是什么？在 ASP.NET 中試圖對實作 IHtmlString 的物件進行 HTML 編碼會造成空操作指令，

(P054)

根據 Razor ，視圖模板就是一個 HTML 頁面加上幾個占位符和代碼片段，

(P056)

Razor 視圖模板實質上是一個 HTML 頁面加上幾個代碼段，也稱為代碼碎塊，

Razor 代碼塊的標志是開頭使用 @ 字符，更為重要的是，不需要顯式關閉這些代碼塊，

(P057)

Razor 模板就是帶有封裝了可執行陳述句和 HTML 幫助器的 @ 運算式的普通 HTML 標記檔案，

可以通過在 @{code} 塊中進行封裝來在任意位置插入整段的多行代碼，

(P058)

來源于運算式的單個陳述句可以通過使用括號在同一運算式中組合，

在你需要放置一個函式呼叫時，括號也起作用，

(P059)

Razor 視圖引擎在使用時，生成的視圖物件是一個在 System.Web.Mvc 程式集中定義的 WebViewPage 類的實體，這個類集成了決議標記和呈現 HTML 的邏輯，該類上的公共屬性對于在實際模板中撰寫的任何代碼碎片都可用，

(P060)

控制器能以各種方式將資料傳遞給視圖，它可以使用全域字典，如 ViewBag 或 ViewData ，更好的是，控制器可以使用為特定視圖量身定做的強型別物件，

要從代碼碎塊中使用 ViewBag 或 ViewData ，不需要采取任何特別措施，只需要撰寫讀入或寫進字典的 @ 運算式即可，相反，要使用強型別的視圖模型，需要在模板檔案的頂部宣告實際的型別，

通過使用 Model 屬性訪問視圖模型物件中的屬性，

如果 Model 參考了具有子屬性的物件，那么可以使用 Model.Xxx 來參考每個子屬性，

在 Razor 中，布局頁面扮演著 Web Forms 中母版頁的角色，布局頁面是一個標準的 Razor 模板，視圖引擎會將定義的任意視圖呈現出來，從而將外觀和感覺與網站版面統一起來，

(P061)

使用 Razor ，可以在 Views 檔案夾中定義一個特殊檔案，該檔案在每個視圖構建和呈現之前進行處理，這個檔案被稱為 _ViewStart.cshtml ，是任何與視圖相關的啟動代碼的理想容器，其中包括決定使用哪個布局的代碼，

執行 RenderBody 方法會導致實際視圖中的任何代碼都注入布局模板，

實際視圖模板中的代碼會在視圖和布局合并之前進行處理，

(P062)

從 ASP.NET MVC 4 開始，波浪號 (~) 通過 Razor 引擎自動擴展，雖然 Url.Content 的使用依然受到支持，但已不再必要，

在布局模板中，通過在希望節所出現的位置放置一個對 RenderSection 的呼叫來定義注入點，

每一個節都由名稱標識，并能標記為可選，

如果視圖模板不包含所需的節，會得到一個運行時例外，

(P063)

可以在 Razor 視圖模板的任何位置定義節的內容，

WebViewPage 類提供了一個方便的 IsSectionDefined 方法，可以用在 Razor 模板中確定給定的內容是否已被指定，

請記住節的名稱不區分大小寫，

可以對 Razor 布局進行任意程度的嵌套，

(P066)

ASP.NET MVC 設計的黃金法則宣告，視圖會接收但不會計算它要顯示的任何資料，可以通過三種非獨占性的方式傳遞資料 : ViewData 字典、 ViewBag 字典以及量身定做的容器物件，也常被稱作視圖模型物件，

ViewData 屬性直接由 Controller 類公開，它是 名稱-值 字典物件，其編程模型類似于使用 Session 或其他 ASP.NET 內部物件，

存盤在字典中的任何資料都會被當作一個物件來處理，需要轉換、裝箱、或這兩者一起以便被視圖所用，可以按需在字典中創建條目，字典的生存周期與請求的生存周期是一樣的，

請記住，不會被限于僅在 ViewData 字典中存盤字串，

ViewData 字典非常適合于簡單的解決方案和相對較短生命周期的應用程式，隨著字典條目數量和視圖數量的增長，維護會成為一個問題，因此尋找其他選項時應該擺脫 ViewData ，

(P067)

ViewBag 屬性也在 Controller 類上進行定義，它提供了一個更加靈活的將資料傳遞給視圖的工具，

基于動態型別的任何運算式都會被編譯成在運行時解釋，

ViewBag 的語法比 ViewData 的語法更為簡潔，但就我看來，這就是所有的區別了，

ViewBag 至少需要是 ASP.NET MVC 3 和 .NET 4 ，而 ViewData 的適用范圍是 ASP.NET MVC 的任何版本和 .NET 2.0 ，

(P068)

處理軟體中復雜性的唯一證明有效的方法是合適的設計，

為每個視圖定義一個物件模型可以幫助跟蹤視圖的真實所需，建議為每一個添加到應用程式中的視圖定義一個視圖模型類，

視圖模型物件是一個只有資料而 (幾乎) 沒有行為的普通資料傳輸物件，

(P069)

ASP.NET MVC 基礎架構保證了 ViewData 和 ViewBag 始終可用于視圖物件而無需開發人員的任何干預，而自定義視圖模型物件就不是這樣了，

當使用一個視圖模型物件時，必須在視圖模板中宣告該視圖模型型別，

要在視圖模板中檢索視圖模型物件，可以使用在 WebViewPage 和 ViewPage 上都定義過的 Model 屬性，

(P070)

雖然每個視圖都應該有自己的模型物件，但限制要處理的類的數量通常是一個好選擇，要在多個視圖中重用模型類，往往需要生成一個類的層次體系，

視圖模型類最終是為視圖建模而不是為資料，

對于至少中等復雜程度和中等持續時間的任何 ASP.NET MVC 應用程式來說，強型別視圖模型是唯一安全而可行的解決方法，

【第03章】

(P075)

通常存在至少兩種完全不同的模型 : 領域模型和視圖模型，

“領域模型” 描述在中間層使用的資料，預期會為填充業務領域的物體和關系提供可靠的表示，這些物體一般通過資料訪問層來持久保存，并且通過實作業務流程的服務來使用，

視圖模型只描述了表示層中正在處理的資料，

應該始終意識到在兩個不同層中運行著兩種不同模型的事實，

(P076)

要將輸入資料傳遞給控制器，需要以某種方式把資料封裝起來，

(P078)

輸入模型提供了正在提交到控制器的資料的表示，視圖模型提供了正在視圖中進行處理的資料的表示，最后，域模型是在中間層中操作的域特定物體的表示，

類的最終結構和關系圖取決于你自己，

模型系結是指將通過 HTTP 請求所提交的值系結到控制器方法所用的引數的程序，

(P079)

默認模型系結器使用基于規則的邏輯，將提交的值的名稱與控制器方法中的引數名稱相匹配，

默認模型系結器會使用所有已注冊的值提供程式將提交值與方法引數進行匹配，

可以在方法簽名上列出的引數的數目沒有上限，但是，一個容器類往往比一個各種引數的長串列要好，對于默認模型系結器，無論列出一系列引數，還是復雜型別的一個引數，結果幾乎相同，這兩種方案都完全受到支持，

(P083)

模型系結器能夠處理該復雜型別，就像它處理單個值的情況一樣，

對于宣告的型別中的每一個公共屬性，模型系結器都會尋找其關鍵字名稱與屬性名稱相匹配的提交值，匹配不區分大小寫，

(P089)

默認系結器通過匹配與引數名稱一起上傳的輸入檔案元素的名稱來實作系結，但是引數 (或引數型別上的屬性) 必須宣告為 HttpPostedFileBase 型別，

(P090)

默認情況下，任何 ASP.NET 請求都不能超過 4MB ，這個數字包含了所有的上傳、標頭、正文以及正在傳輸的任何內容，可以通過 web.config 檔案中 httpRuntime 部分的 maxRequestLength 條目來配置各個級別的上傳閾值，

(P092)

默認的模型系結器會強制將請求引數命名為在目標操作方法上與形參相匹配的指定名稱，

(P095)

請記住，撰寫模型系結器時，并不局限于僅從提交資料中獲取用于模型的資訊，雖然這代表了大多數常見情形，可以從任何位置 (比如從 ASP.NET 快取和會話狀態中) 獲取資訊，決議并將它存盤在模型中，

(P096)

區域系結器總是優先于全域定義系結器，

(P102)

模型系結器提供了將表單提交值反序列化為簡單型別和復雜型別的完全控制權，

【第04章】

(P103)

HTML 幫助器，可以自動為任何簡單或復雜的型別創建簡單而實用的視圖和編輯器，

資料批注，可以用宣告方式設定對某欄位的內容及其顯示行為的預期，

模型系結器，可以將提交的值序列化為對服務器端的處理更為適用的物件，

(P112)

PRG 模式建議每個 POST 請求在經過處理后，以重定向到一個通過 GET 訪問的資源而結束，

(P117)

在 ASP.NET MVC 中，模板化幫助器使用與類成員相關聯的元資料來決定如何顯示或編輯資料，元資料通過元資料提供程式物件讀取；默認的元資料提供程式會從資料批注特性中獲取資訊，

(P118)

資料批注是特性，而特性通常不包含代碼，它們僅僅表示其他模塊需要使用的元資訊，通過使用資料批注，模型物件就被元資料修飾了，這并不能預計產生任何的可見影響 : 一切都取決于其他組件如何使用元資料，

資料批注包括描述性特性和驗證特性，描述性特性指示偵聽器如何顯示或編輯資料，驗證特性指示偵聽器如何驗證模型類的內容，

(P119)

注意如果沒有使用 DisplayForModel 或 EditorForModel 自動生成輸入表單，就不需要資料批注，

(P122)

顯示 / 編輯 幫助器在很大程度上可以自定義，任何自定義的模板都包含一個位于 Views\[Controller]\DisplayTemplates 檔案夾用于顯示幫助器的自定義視圖，和一個位于 Views\[Controller]\EditorTemplates 檔案夾用于編輯幫助器的自定義視圖，

(P141)

當開啟客戶端驗證時，所有內置的資料批注特性都會獲得一個客戶端行為，并盡可能在瀏覽器中執行其在 JavaScript 中的驗證，如果驗證失敗，就不會向 Web 服務器發出請求，

【第05章】

(P151)

在很大程度上，可以把 ASP.NET MVC 視為經典 ASP.NET 運行時環境的特別版本，其僅用于支持不同的應用程式和編程模型，

ASP.NET MVC 應用程式對構成 ASP.NET 生態系統的任何內置組件都具有完全訪問權，包括 Cache 、 Session 、 Response ，以及身份驗證和錯誤處理層，

(P152)

HttpResponse 物件的公共介面可以設定 cookies 和內容型別、附加標頭、以及針對回應資料的快取將指令傳遞給瀏覽器，另外， HttpResponse 物件還有助于重定向到其他 URL ，

在 ASP.NET 中，當呼叫 Response.Redirect 時，會向瀏覽器回傳一個 HTTP 302 代碼，表明所請求的內容現在可以從另一個指定位置獲得，

(P155)

ASP.NET MVC 基礎架構在內部使用會話狀態，也可以在代碼中這樣做，

(P156)

ASP.NET MVC 基礎架構會使用會話狀態來保持 TempData 字典的內容，

在會話狀態中存盤的任何資料都會作為一個 Object 回傳，

(P157)

在 ASP.NET 中，內置的快取功能是通過 Cache 物件實作的， Cache 物件是在每一個 AppDomain 基礎上創建的，并且在 AppDomain 運行期間它仍然保持有效，

(P161)

MemoryCache 類繼承自基類 ObjectCache ，通過派生你自己的快取物件，可以控制內部存盤以及快取資料的管理，

請記住， ObjectCache 及其派生的型別并不適用于提供分布式快取功能，

(P165)

來自微軟的關于例外處理的另一項主要原則是，對于一般的錯誤使用內置型別，對于特定于你正在創建的應用程式，要創建應用程式專屬的例外型別，

(P171)

在 ASP.NET 開發人員之間比較流行的工具是錯誤日志記錄模塊和處理程式 (Error Logging Modules And Handlers , ELMAH) ， ELMAH 本質上是由一個 HTTP 模塊構成，一旦配置，就會攔截應用程式級別的 Error 事件，并根據大量后端存盤庫的配置將其記錄下來，

當自定義錯誤標志關閉時，攔截模型系結錯誤的唯一辦法就只能是借助于 Global.asax 中的集中式錯誤處理程式，

(P173)

全部捕獲規則需要在路由串列的最底部運行，

在 ASP.NET MVC 中并沒有現成的 Error 控制器，但強烈建議創建一個，

(P174)

通過使用錯誤控制器，可以提高應用程式的友好性，并為搜索引擎對其進行優化，

全部捕獲路由就是一個為 URL 選出的不匹配任何其他路由的路由，

(P181)

在 ASP.NET MVC 中，當你只想呈現視圖的時候要使用 Html.RenderPartial ；當你想要取回 HTML 標記并自己撰寫到流時，要使用 Html.Partial ，

【第06章】

(P190)

Windows 身份驗證很少應用于實際的互聯網應用程式，

表單身份驗證是最常用的收集和驗證用戶憑據的方式，例如使用用戶賬戶資料庫進行驗證，

在 ASP.NET MVC 和 Web Forms 中，是通過根 web.config 檔案中的 <authentication> 部分選擇身份驗證機制的，

默認情況下， ASP.NET MVC 應用程式會被配置為使用 Forms 身份驗證，

當要限制對某操作方法的訪問時，請使用 Authorize 特性，并確保只有通過身份驗證的用戶可以執行它，

如果將 Authorize 特性添加到控制器類，那么控制器上的任何操作方法都將需要進行身份驗證，

(P191)

絕對不要將 Authorzie 特性用作全域篩選器，

AllowAnonymous 方法派上用場的情況是，當把 Authorzie 應用在類級別時，之后需要啟用對一些方法的自由訪問，尤其是登錄方法，

【第07章】

(P231)

作業執行緒服務或應用程式服務屬于系統的應用程式層，應用程式層是實作從用例中所產生的應用程式邏輯的地方，這一層不能重用，因為它是特定于應用程式 (和前端) 的，可重用性要推至下一層的域層中，意即核心功能是可重用的 (也就是域) ，但呈現作業流會特定于應用程式，

ASP.NET MVC 是一個旨在方便測驗和推動像關注點分離 (SoC) 和依賴注入 (DI) 這樣的重要原則的框架，

(P239)

層 (layer) 是指邏輯上的分離，而層級 (tier) 是指物理上的分離，

(P240)

表示層截獲請求并將其傳遞到應用程式層，應用程式層 (也稱為服務層) 是應用程式實作用例的區段，在這一點上，它特定于每個應用程式并且不可重用，應用程式層將端點公開給表示層，并將它從系統的其他部分解耦，應用程式層會安排域服務和外部服務，以及可能用到的特定業務的企業組件，最后，基礎架構層會封裝對資料的訪問，

(P241)

就 ASP.NET MVC 而言，應用分層架構模式意味著將請求的回應結果委托給作業執行緒服務，接著，會聯系后端獲得回應，回應包含了表示層所需格式的資料，

應用程式層包含用例的實作，可以將其看作起編排作用的組件的聚合，

(P242)

物件模型、域模型和物體模型是常常可以互換使用的相似術語，

物件模型是普通、泛型的物件集合，

域模型是特殊型別的物件模型，其中的每一個類都是 POCO 、聚合根會被識別出、工廠會被用于建構式、并且大多數時候值型別往往會取代基元型別，

物體模型基本上是一個表明類 (大多是貧血類) 的集合的物體框架術語，可能是 POCO ，也可能不是，貧血類有資料，但幾乎沒有行為，

(P243)

專注于視圖的物件模型是基于資料傳輸物件 (data-transfer objects , DTO) 的， DTO 是一個普通的容器類 (只有資料，沒有行為) ，用于在層、層級之間甚至同一層之內傳遞資料，

基礎架構層基本上就是資料庫層，重命名后降低了放在資料和模型上的焦點和重點，

(P244)

基礎架構層處理持久性，它由存盤庫類構成，每個重要物體 (或者，也可以稱為聚合根) 配有一個，存盤庫類使用一個指定的存盤 API 來實作持久性，存盤庫類的實作在邏輯上屬于資料訪問層，存盤庫類會聚集多個服務于物體資料訪問需求的方法，在存盤庫中，通常可以找到讀取、添加、洗掉和更新資料的方法，

存盤庫向應用程式層公開介面并在內部使用存盤 API ，

在每個物體的基礎上 (確切地說，只是主要物體) 創建的存盤庫是通往實際持久層的大門，

(P245)

高級別的類應該總是依賴于它們所需低級別類的抽象，

(P246)

服務定位器模式定義了一個組件，它知道如何檢索應用程式可能需要的服務，呼叫方無須指定具體的型別；呼叫方通常表示介面、基型別或者是以字串或數字編碼形式存在的服務昵稱，

(P247)

依賴注入模式表明你要以這樣一種方式設計類 : 它從外部接收其所有依賴性，

(P248)

在類中使用依賴注入的時候，開發人員必須作出的一個關鍵決定是，如何以及在何處讓代碼注入，有三種方式可以把依賴性注入到類中 : 使用建構式、一個可設定的屬性、或一個方法的引數，這三種方式都有效，最終的選擇取決于你，一般的共識是將建構式用于必要的依賴性， setter 方法用于可選的依賴性，

(P249)

IoC 容器是一個專門創建用來支持 DI 的框架，

【第08章】

(P257)

TempData 字典用來存盤從邏輯上講屬于當前請求的資料，但必須要跨越一個重定向來使用，

根據 PRG 模式，應該用一個 GET 重定向到顯示結果的視圖來終止一個 POST 請求，

默認情況下， TempData 字典會將其內容保存到會話狀態，直接使用 Session 與借助 TempData 的主要區別是，任何存盤在 TempData 中的資料都會在連續請求終止后自動清除，換句話說，資料駐留在記憶體中只會用于兩個請求 : 當前請求和下一個重定向，歸根結底， TempData 帶給記憶體的壓力更小，

(P260)

對于從頭開始構建的新系統， DI 是該優先考慮的；它會使代碼保持得更整潔，更便于閱讀和測驗，使用 DI ，依賴性在類的簽名中是顯式的，不過，周邊框架要求對依賴性的準備和注入負完全責任，對于現有系統， SL 更容易接入使用，因為它只會要求你將呼叫封裝在一個公開介面的黑盒中，

(P261)

單獨注冊的組件對應用程式來說一定是唯一的一個組件，多次注冊的組件可以注冊多個實體并向系統的其他部分公開，

(P266)

每個控制器方法可以用多個篩選器來修飾，

可以把篩選器應用于單個方法，也可以應用于整個控制器類，如果將篩選器應用于控制器類，則會對所有由控制器公開的操作方法產生影響，與此相反的是，全域過濾器是在應用程式啟動時注冊并自動應用于任何控制器類的任何操作，

(P268)

在 ASP.NET Forms 中，壓縮一般是通過 HTTP 模塊攔截請求和壓縮回應來實作的，你還可以在互聯網資訊服務 (IIS) 級別開啟壓縮，這兩個選項在 ASP.NET MVC 中都好用，決定使用哪一個選項取決于你，

ASP.NET MVC 提供了特別容易實作的第三個選項 : 一個對壓縮事件進行設定的特定操作篩選器，用這種方式，可以在不必撰寫 HTTP 模塊的情況下控制某種特定的 URL ，

【第09章】

(P305)

從設計的角度看，可測驗軟體本質上是更好的軟體，

當你把控制性、可見性和簡單性應用于軟體開發程序中時，最侄訓獲得只通過約定介面就能進行互動的相對較小的構建塊，

(P307)

指示你的類面向介面運行而不是面向實作運行是現代軟體開發的五大支柱之一，

開發的五項原則常常被總結為首字母縮寫的 SOLID 一詞，

(P308)

在現代軟體中，撰寫面向介面而非面向實作的代碼這一概念已被廣為接受和應用了，但它也常常被另一個更具體的概念所掩蓋 : 依賴注入，

可以說基于介面編程的整個概念是在依賴反轉原則 (DIP) 中進行硬編碼，且依賴注入是應用 DIP 的一種流行設計模式，

(P313)

測驗方法的典型設計可總結為三個縮寫的 “A” ，分別代表著設定、作用、斷言，

【第10章】

(P339)

ASP.NET Web API 是一個新的框架，其明確意圖是支持和簡化可以由各種客戶端所使用的 HTTP 服務的構建程序；尤其是 HTML 網頁和移動應用程式，

Web API 是一個精心設計的框架，它用于為 .NET 應用程式構建 RESTful (具象狀態傳輸) 和遠程程序呼叫 (RPC) 風格 HTTP 服務，

(P340)

WCF 的最初構想是透過種類繁多的傳輸層來支持 SOAP 和 WS-* ，這些傳輸層包括 TCP 、 訊息佇列 (MSMQ) 、命名通道，以及最后也是最重要的一個 : HTTP ，

(P341)

Web API 非常適合于現在似乎常見的應用程式場景 : 客戶端應用程式需要呼叫遠程后端來下載資料或請求處理，客戶端應用程式可以采用多種形式 : JavaScript 密集型網頁、富客戶端或移動應用程式，

JSON 格式是在客戶端和 HTTP 服務之間序列化物件的理想格式，

(P343)

Web API 基礎架構與 ASP.NET MVC 基礎架構是獨立的，不具有隱藏的依賴性，

(P344)

Web API 模塊是一個獨立的基于 HTTP 的服務，能夠被許多應用程式托管，而 ASP.NET MVC 應用程式大概是最常用的宿主型別，

REST 被定義為專注于通過 Web 協議、特別是 HTTP 協議識別和處理資源的一種架構風格，

(P351)

構建一個在 ASP.NET MVC 應用程式內部的 Web API 模塊是由該 ASP.NET MVC 應用程式托管的，

要使用 Web API 模塊，你只需要使用 ASP.NET MVC 站點即可，

從 Web 客戶端內部， Web API 前端就是一個簡單的 HTTP 端點集合，可以使用 jQuery 工具來放置 HTTP 呼叫，或者使用 KnockoutJS 工具來呈現出物件集合，

(P352)

$.ajax jQuery 工具讓你能夠指定 HTTP 動詞和標頭，這樣一來，你就能夠輕易地作好呼叫 Web API 后端上的任意型別操作的呼叫設備，

由于 Web API 模塊是一個普通的 HTTP 前端，因此從一些 .NET 服務器端代碼內部呼叫它就與從任何其他型別的遠程端點呼叫沒什么區別，

(P354)

作為使用 WebClient 進行遠程呼叫的替代選項，可以使用最新的 HttpClient ，它是老式可靠的 WebClient 客戶端的修改及更豐富的版本， HttpClient 是在 System.Net.Http 名稱空間中定義的，

【第11章】

(P369)

一個完整的 Ajax 應用程序是將頁面互動減少到最低限度的 Web 應用程式，

作為 ASP.NET MVC 開發人員，你要準備好撰寫越來越多的 JavaScript 代碼，

(P371)

一個設定為 undefined 的變數不會被任何代碼觸及到；而包含 null 的變數會通過你代碼中的一些路徑被分配到某個值，

如果在未賦值的變數上運行 typeof ，就會得到 undefined —— 它本身就是一種獨特的型別，如果在被賦予 null 值的變數上運行 typeof ，你會獲得 object ，

在定義變數時，你應一直使用 var 關鍵字作為對決議器和你自己的提示，

var 關鍵字并非絕對必要，但強烈建議使用，

如果通過使用 var 對變數進行了宣告，那么在函式內定義的變數就會僅限于這個函式，如果沒有宣告，變數會被視為全域的，但它們會保持 undefined ，直到函式執行一次，

在全域范圍中宣告的變數都是全域變數，無論是否使用 var ，

(P372)

JavaScript 運行時環境會將全域變數存盤為通過 this 關鍵字參考的隱藏物件的屬性，

缺失 var 的話，你最侄訓得的就是全域變數；在賦值中鍵入錯誤的變數名稱，也會得到一個新的全域變數，

(P380)

嵌套 jQuery 函式被映射成瀏覽器視窗物件的擴展并且用流行的 $ 函式作為別名，該函式具有以下原型 : function(selector, context) ，選擇器表示在 DOM 上運行的查詢運算式；背景關系表示從 DOM 的哪個部分運行該查詢，如果沒有指定背景關系，則 jQuery 函式會在整個頁面 DOM 中查找 DOM 元素，

jQuery 函式通常回傳一個包裝集 —— 也就是 DOM 元素的集合，非常棒的是，這個包裝集仍然是 jQuery 物件，可使用相同的語法來查詢，并產生一系列查詢，

jQuery 庫的主要目的是運行針對 DOM 的 (明智) 查詢并執行針對回傳項的操作，

一個查詢結果就是一個包裝集，包裝集是包含 DOM 元素集合的物件，元素會按照其在原始檔案中出現的順序被添加到集合中，

(P381)

包裝集并不是一個特殊的資料容器，“包裝集” 是一個表明查詢結果的特定 jQuery 術語，

為了回圈遍歷包裝集中的元素，你要使用 each 函式，此函式會將一個函式用作引數并基于每個元素呼叫它，

可以使用 length 屬性來讀取包裝集的大小，也可以使用 size 函式，但 length 屬性會稍微快一點，

請注意， get 函式 (以及索引) 會中斷 jQuery 的連貫性，因為它會回傳 DOM 物件或 DOM 物件的陣列，你不能進一步將 jQuery 函式應用于 get 呼叫的結果，

(P382)

在 jQuery 中，你有三種基本型別的選擇器 : 基于 ID 的選擇器、層疊樣式表 (CSS) 和標簽名稱，

ID 選擇器會通過 ID 來選取 DOM 元素， ID 選擇器通常只會選擇一個元素，

可以串聯兩個或更多個選擇器來組成更特定的選擇器，

通過多個運算子就能實作串聯，

(P386)

包裝集上的操作 :

1. DOM 操作 —— 創建 DOM 樹、添加 / 移除 元素，或修改現有元素；

2. 系結事件 —— 將處理程式系結和解除系結到由 DOM 元素發起的事件；

3. 樣式化 —— 為所選元素應用、移除或切換 CSS 類并得到或設定單個 CSS 屬性；

4. 可見性 —— 使用過渡效果及持續時間顯示和隱藏 DOM 元素；

(P387)

bind 和 unbind 這對函式用于將回呼函式附加到指定事件，

unbind 函式并不會移除那些通過 onXXX 這樣的特性直接在標記中插入的處理程式，

jQuery 庫還定義了不少直接函式來系結指定事件，

事件處理程式會接收一個 jQuery 內部物件 —— Event 物件，該物件會提供一個用于事件的統一編程介面，該介面與萬維網聯盟 (W3C) 的倡議密切相關，并且它解決了某些瀏覽器造成的輕微不同實作所引起的差異性問題，

(P388)

Event 物件的屬性特征包括滑鼠坐標、事件的 JavaScript 時間、使用的是哪個滑鼠按鈕，以及事件的目標元素等，

如果選擇動態系結而非普通系結，就確保了任何動態添加的能匹配選擇器的元素都會自動附加相同的處理程式，

從 jQuery 1.7 開始，你就該通過 on 和 off 函式來操作動態系結了，

如果使用的 jQuery 版本比 1.7 低，就要使用 live 和 die 方法作為 on 和 off 的替代，其語法稍有不同，因為 live 方法不會將選擇器用作引數，相反它會直接應用于選擇器，

DOM 中的 document 根物件公開了一個只讀的 readyState 屬性，這就是為了讓你獲知 DOM 的當前狀態并獲悉何時你的頁面準備就緒，能夠開始執行腳本，使用 readyState 屬性是一種絕對可行的方式，只是它有一點麻煩，

(P389)

可以在頁面或視圖中擁有多個 ready 呼叫，指定多個 ready 呼叫時， jQuery 會將指定函式推送到內部堆疊并在 DOM 實際準備好之后按順序對其進行處理，

ready 事件僅會在檔案級別觸發；你不能為單個元素或包裝集中的任何元素集合定義該事件，

onload 事件是在 HTML 和所有輔助資源都加載之后呼叫的， ready 事件是在 DOM 初始化之后呼叫的，這兩個事件的運行順序可以隨意安排， onl oad 事件不能確保頁面 DOM 已加載； ready 事件不能確保所有資源已經加載，

(P390)

無侵入性 JavaScript 建立了一個基礎原則 —— 任何網頁中的任何行為都必須是可注入的依賴項并且不是一個構建塊，

限制 UI 依賴項影響的一個方法是使用模板和 KnockoutJS 這樣的特設庫來呈現頁面，

標籤：ASP.NET MVC

上一篇：10、Entity Framework Core 3.1入門教程-執行原生SQL

下一篇：checkbox橫向選擇