《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 模板，以 开头，以 结束。
(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 包的形式提供，允许只选择自己真正需要的功能。