《ASP.NET Core 開發實戰》
========== ========== ==========
[作者] (意) Dino Esposito
[譯者] (中) 趙利通
[出版] 清華大學出版社
[版次] 2019年07月 第1版
[印次] 2019年12月 第2次 印刷
[定價] 79.80元
========== ========== ==========
【前言】
(PVI)
ASP.NET Core 是 ASP.NET 開發人員需要了解的一種技術，是在多種平臺上進行 Web 開發時可供使用的另一種全堆疊解決方案，
【第01章】
(P006)
對于處理必須回傳 HTML 內容的 Web 請求， ASP.NET MVC 編程模型是最靈活、最容易理解的方式，
(P008)
.NET Core Framework 主要被設計為用于 ASP.NET 應用程式，
.NET Core Framework 只能用來撰寫 ASP.NET 和控制臺應用程式，
.NET Core Framework 可與應用程式一同部署，而完整的 .NET Framework 只能安裝到目標機器上，由所有應用程式共享，
(P009)
.NET Core Framework 是從頭開始重新設計的一個新框架，看上去與完整的 .NET Framework 很類似，但是能夠跨平臺作業，
(P010)
ASP.NET Core 包含一個內置的 Web 服務器和一個運行應用程式代碼的運行時環境，
【第02章】
(P015)
ASP.NET Core 有一個全新的運行時環境，只支持一種應用模型 : ASP.NET MVC ，
(P018)
一般來說， Web 根檔案夾是內容根檔案夾的子檔案夾，被命名為 wwwroot ，
(P019)
ASP.NET Core 應用程式需要在一個宿主中執行，宿主負責該應用程式的啟動和生命周期管理，
(P021)
事實上， Configure 和 ConfigureServices 方法都是通過反射來發現并呼叫的，
(P026)
管道由中間件組件構成，這些組件在 Configure 中注冊，對于每個請求，按照注冊的順序呼叫它們，
(P032)
服務定位器模式更容易添加到現有框架中，依賴注入模式則是從頭構建的框架的理想選擇，
ASP.NET Core 中的 DI 框架并不是完善的 DI 框架，無法與業界頂尖的框架一爭，它只是做一些基本的任務，但做得很好，能滿足 ASP.NET Core 平臺的需要，
(P033)
需要重點注意，在 ConfigureServices 中可以注冊外部 DI 框架，不過，在注冊時，必須在啟動類中把方法的回傳型別從 void 改為 IServiceProvider ，
只有少數的 DI 框架被移植到了 .NET Core 中，其中包括 Autofac 和 StructureMap ，
要讓自定義代碼在經典 ASP.NET 中運行，最快捷的方法是使用 HTTP 處理程式，
【第03章】
(P053)
在經典 ASP.NET MVC 中，如果沒有找到與 URL 匹配的路由，將得到 HTTP 404 狀態碼，但是，在 ASP.NET Core 中，任何終止中間件都將有機會來處理請求，
【第04章】
(P067)
控制器管理著請求的整個處理程序，
撰寫控制器類的步驟可總結為兩個 : 實作一個類，然后在該類中添加一些公有方法，在運行時該類可以作為控制器被發現，而這些方法則可作為操作被發現，
(P068)
MVC 應用程式收到的只是一個待處理的 URL ，這個 URL 必須以某種方式映射到一個控制器類和一個公有方法，
(P069)
傳統路由和特性路由并不是互斥的，二者可用在同一個應用程式中，
特性路由始終是打開的，導致通過特性定義的路由比傳統路由的優先級更高，
只要控制器類的名稱帶有 Controller 后綴，并且繼承自 Controller 基類，就可以被系統發現，
(P070)
操作呼叫程式將 HTTP 背景關系注入控制器實體，在控制器類內運行的代碼可通過 HttpContext 屬性方便地訪問 HTTP 背景關系，
(P073)
ASP.NET Core 提供了內置的依賴注入 (DI) 框架，開發人員可通過這個框架來注冊抽象型別 (如介面) 及其具體型別，在請求抽象型別的參考時，回傳該抽象型別的具體型別實體的作業則由框架來完成，
(P075)
在 Web 上，當點擊鏈接或者在地址欄中輸入 URL 時，是在執行 HTTP GET 命令，當提交 HTML 表單的內容時，是在執行 HTTP POST 命令，
(P080)
控制器操作方法能夠訪問 HTTP 請求傳遞的任何輸入資料，
(P081)
撰寫操作方法體時，可以直接訪問熟悉的 Request 物件及其子類集合 (如 Form 、 Cookies 、 Query 和 Headers) 提交的任何輸入資料，
Request.Query 字典包含從 URL 的查詢字串提取的引數及其對應值的一個串列，注意，在搜索匹配項時，不考慮大小寫，
(P082)
模型系結器按精確的順序將引數與傳入的資料匹配起來，它首先檢查是否能夠在路由引數上找到匹配，然后檢查表單提交的資料，最后檢查查詢字串資料，
(P083)
默認系結器能夠映射所有的基本型別，如 string 、 int 、 double 、 decimal 、 bool 和 DateTime ，以及這些型別的相關集合，
(P085)
模型系結器會尋找鍵名稱與屬性名稱匹配的提交值，這種匹配是不區分大小寫的，
(P090)
在 ASP.NET Core 中， Web API 框架 (包括其自己的控制器服務和操作結果型別) 已被集成到主框架中，
【第05章】
(P099)
從架構的角度來看，回傳 HTML 標記的請求與回傳純本文或 JSON 資料的請求并沒有區別，
(P101)
呼叫 View 函式將觸發視圖引擎，回傳一個物件，該物件封裝了要使用的 Razor 模板檔案 (一個擴展名為 .cshtml 的檔案) 的名稱和一個視圖模型物件，后者包含了要在最終的 HTML 布局中顯示的資料，
(P102)
視圖引擎是 MVC 應用程式模型的核心組件，負責從視圖創建 HTML ，
在控制器方法內，通過呼叫 View 方法來呼叫視圖引擎，
母版頁視圖默認為一個名為 _Layout.cshtml 的 Razor 檔案，其 HTML 布局是視圖的基礎，
(P104)
在 ASP.NET Core 中，每個應用程式只有一個默認的視圖引擎 : RazorViewEngine 類，
除了使用 ASP.NET Core 提供的 RazorViewEngine 類，也可以基于自定義語法來實作自己的視圖引擎，
(P105)
使用區域就像是使用多個子應用程式，是將較大的應用程式磁區成較小的片段的一種方法，
使用區域時，他們會對路由產生影響，在傳統路由中，區域的名稱是另一個要考慮的引數，
(P110)
Razor 模板檔案實際上就是 HTML 模板，其中穿插了一些用 C# 語言 (或者 ASP.NET Core 平臺支持的其他任何語言) 撰寫的代碼塊，
@符號告訴決議器，在這個位置將發生靜態內容到代碼段的過渡，
(P112)
當多個 Razor 檔案起作用時，編譯程序將分步驟進行，首先處理布局模板，然后是 _ViewStart 和實際的視圖，之后合并輸出，這樣 _ViewStart 中的公共代碼將在視圖之前渲染，而視圖則在布局內輸出其內容，
(P113)
控制器向視圖傳遞資料時，最簡單的方法是將資訊存入一個 名稱 / 值 字典中，
(P115)
對于使用 ViewData 這樣弱型別的字典，最有說服力的理由是在編程時，它們使用起來簡單快捷，
(P116)
一般來說，在向視圖傳遞資料時，強型別視圖模型是優先選擇的方法，
視圖模型類完全代表了要渲染到視圖的資料，類的結構應該盡可能與視圖的結構匹配，
(P117)
一般來說，應該努力讓每個 Razor 視圖模型有一個專門的視圖模型類，
可以接受把物體模型直接傳遞給視圖的唯一一種情況是確實有一個 CRUD 視圖的時候，但是，坦白講，純粹的 CRUD 視圖如今只存在于教程和總結文章中，
(P118)
在 ASP.NET 中，可以將 DI 系統中注冊的任何型別的實體注入視圖中，這是通過 @inject 指令實作的，
ViewData 字典和 @inject 指令結合起來時，為從 Razor 視圖中獲取需要使用的任何資料提供了一種強大的、極為快速的方法，
(P119)
Razor 頁面就像一個無布局的 Razor 視圖，但是它們使用的根指令是 @page ，Razor 頁面完整支持 Razor 語法，包括 @inject 指令和 C# 語言，
(P120)
需要注意， @page 指令會影響其他支持的指令的行為，所以必須是頁面中的第一條 Razor 指令，
不能將 Razor 頁面放到 Pages 檔案夾之外，
【第06章】
(P123)
Razor 檔案是一個文本檔案，包含兩個主要的語法項 : HTML 運算式和代碼運算式，
(P124)
無論選擇什么編程語言，@ 字符總是表明 Razor 代碼運算式的開始位置，
(P126)
HTML 幫助程式是 HtmlHelper 類的一個擴展方法，抽象來講， HTML 幫助程式只不過是一個 HTML 工廠，
(P127)
xxxFor 幫助程式與基礎版本的區別在于，它只接受一個 Lambda 函式作為引數，
當用來填充視圖的資料被分組到一個模型物件中時， xxFor 版本特別有用，
(P128)
在 Razor 中，布局模板扮演了母版頁的角色，布局模板定義了視圖引擎在任何映射的視圖中渲染的骨架，使得網站的對應部分有了一致的外觀和感覺，
布局模板是一個完整的 HTML 模板，以 <html> 開頭，以 </html> 結束，
(P129)
在任何視圖中，在參考圖片、腳本和樣式表等資源時，都建議使用波浪號運算子 (~) 來指代網站的根目錄，
(P130)
所有布局都強制至少有一個注入點，供注入外部視圖內容，這個注入點就是對方法 RenderBody 的呼叫，
每個節都通過其名稱標識，如果沒有標記為可選，那么認為每個節都是必須存在的，
(P131)
可以在 Razor 視圖模板的任何位置定義一個節的內容，
【第07章】
(P151)
DI 框架有時也稱為控制反轉 (Inversion-of-Control, IoC) 框架，
DI 框架實際上就是將抽象型別 (通常是一個介面) 映射到一個具體型別，
(P153)
動態決議允許指定一個回呼函式來決議依賴，
(P154)
必須呼叫 IServiceCollection 的某個 AddXxx 擴展方法來把自己的型別添加到 DI 系統中，以及將任何系統抽象型別系結到不同的實作，
(P164)
要利用好一種強大的技術，最好的辦法就是把這種技術放到業務領域的背景關系中，
對于軟體技術，如果沒有合理有效的架構，很難創建復雜的應用程式，
(P165)
在 ASP.NET MVC 應用程式中，表示層由控制器構成，應用層由控制器特定的服務類構成，
(P166)
當一個物體可用于輸入、邏輯、持久化和視圖時，說明處理的應用程式特別簡單，
在 ASP.NET 中，任何輸入資料都被封裝到一個 HTTP 請求中，不管輸入資料來自查詢字串、表單提交的資料還是 HTTP 頭或 cookie ，
(P167)
建議為每個控制器創建一個服務類，讓控制器的操作方法服從服務類，
服務類中的方法將接受輸入模型中的類，回傳視圖模型中的類，
應用層位于表示層和后端之間，進行任何必要的轉換，
當大量使用應用層時，控制器就成為精簡的控制器，因為它們把全部協調作業移交給了應用層，最后，應用層是可以完整測驗的，并且完全不知道 HTTP 背景關系，
存盤庫是最簡單和最著名的領域服務示例，領域服務類通常會參考資料訪問層，
(P169)
應該把例外處理中間件放到管道的最頂端，以確保能夠檢測到應用程式沒有捕捉的所有可能發生的例外，
(P170)
HTTP 背景關系的 Features 物件是獲取未清除的例外資訊的官方工具，
ASP.NET Core 的模塊化程度極高，需要使用的幾乎每個功能都必須被顯式啟用，
【第08章】
(P182)
所有宣告都是平等的，但是有一些宣告比其他宣告更加平等，
【第09章】
(P208)
layer 指的是應用程式組件之間的邏輯分離，而 tier 指的是物理上不同的應用程式和服務器，
(P219)
NoSQL 存盤主要用作一種快取形式，不常用作主資料存盤，
(P221)
EF Core 只支持 Code First 方法，這意味著它需要一組類來描述資料庫和容器表，
【第11章】
(P260)
HTML 表單是由一組 INPUT 元素構成的，當按下某個提交按鈕時，這些 INPUT 元素的值將被流傳輸到一個遠程 URL ，
【第12章】
(P278)
分部視圖不只使結果頁面組件化，加強重用和關注點隔離；而且更容易在客戶端重繪頁面的一部分，而不需要重新加載整個頁面，
【第14章】
(P315)
ASP.NET Core 應用程式本質上是一個獨立的控制臺應用程式，它為實際的應用程式模型 (最有可能是 MVC 應用程式模型) 設定宿主環境，
(P324)
對于 ASP.NET Core 2.0 ， Kestrel 是最常用的內部 HTTP 服務器，這是一個基于 libuy 的跨平臺 Web 服務器，而 libuy 是一個跨平臺的異步 I/O 庫，
(P325)
.NET Core 支持的所有平臺和版本，都支持 Kestrel ，
(P327)
反向代理將實際的 Web 服務器與來自各種用戶代理的請求完全隔離開，
【第16章】
(P362)
ASP.NET Core 應用程式的跨平臺本質是最重要的業務價值，
(P364)
ASP.NET Core 中性能提升的另外一個原因在于其模塊化，
整個 ASP.NET Core 框架以 NuGet 包的形式提供，允許只選擇自己真正需要的功能，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/1649.html
標籤：.NET Core