Core 20 入门

　　通过 ASP.NET Core，可以轻松创建运行速度快且可移植的跨平台 Web 应用程序。本文将逐步介绍如何开发简单的 ASP.NET Core 网站，并说明项目中每个文件的作用。

　　dotnet new 命令可用于新建 .NET Core 项目。运行不含其他任何参数的 dotnet new 会列出可用的项目模板，如图 1 所示。如果熟悉旧版 .NET CLI，就会发现 2.0 版中有许多新模板。

　　包含 Razor 页面的 ASP.NET Core Web 应用程序：Razor 页面是一项 ASP.NET Core 2.0 新功能，支持用户创建能够直接处理请求（无需使用控制器）的页面。如果方案涉及基于页面的编程模型，这是理想之选。

　　对于本次演练，将从全新的 Razor 页面模板入手，具体方法是执行 dotnet new razor。项目一创建完成，就应该可以通过执行 dotnet run 运行项目。在旧版 .NET Core 中，一直以来都必须先执行 dotnet restore，才能安装必要的 NuGet 包。

　　不过，自 .NET Core 2.0 起，restore 命令现在由依赖它的 CLI 命令自动运行。开始执行 dotnet run，并转到应用程序在侦听的 URL（很可能是），以测试模板网站。应该会看到所呈现的 Web 应用程序（如图 2 所示）。

　　恭喜！现已发布首个 ASP.NET Core 2.0 应用程序！ 至此，已有一个简单的 Web 应用程序正在运行，接下来将探究项目所含内容，以便更好地了解 ASP.NET Core 的工作原理。

　　要介绍的首个文件是项目文件本身（.csproj 文件）。此文件告知 MSBuild 如何生成项目，即依赖哪些包、定目标到哪一版 .NET Core 等。如果之前探究过 .csproj 文件，就会发现此项目文件要比原来小很多。

　　我们做出了很大努力，让 .csproj 文件变得更简短、更具可读性。一项有助于缩减项目文件的显著变化是，不再需要明确列出源文件。

　　相反，.NET Core SDK 会自动编译所有 .cs 文件，无论它们是位于项目文件旁边，还是位于 .csproj 目录下的任意目录中。同样，发现的所有 .resx 文件也都会作为资源嵌入。

　　如果不想编译所有这些 .cs 文件，可以从“编译项组”中删除它们，也可以将 EnableDefaultCompileItems 属性设置为 false，从而完全禁用默认编译项。

　　Program.cs 表示应用程序的入口点。由于 ASP.NET Core 应用程序是控制台应用程序，因此与所有控制台应用程序一样，都包含在应用程序执行时启动的 Main 方法。

　　此配置需要执行一些步骤，如指定 Web 服务器、设置内容根路径和启用 IIS 集成。

　　新方法 CreateDefaultBuilder 可创建现成的 IWebHost，且最常见配置均已完成，从而简化了此过程。除了指定前面列出的项之外，CreateDefaultBuilder 还负责处理一些设置（设置配置信息，并注册默认日志提供程序），这些以前是在 Startup.cs 中进行处理。

　　接下来，将简单了解一下 CreateDefaultBuilder 中执行的最重要调用及其用途。虽然这些调用全都是由 CreateDefaultBuilder 自动执行，但最好也了解一下幕后运作机制。

　　UseContentRoot 为应用程序指定根目录，以便 ASP.NET Core 可以在其中找到整个网站内都有的内容（如配置文件）。请注意，这不同于 Web 根（其中包含的是静态文件），尽管默认情况下 Web 根是以内容根为依据 ([ContentRoot]/。

　　ConfigureAppConfiguration 创建配置对象，以便应用程序可以使用此对象读取运行时设置。通过 CreateDefaultBuilder 调用时，它将会从 appsettings.json 文件、环境专属 .json 文件（若有）、环境变量和命令行参数读取应用程序配置设置。如果是在开发环境中，还将使用用户密钥。这是 ASP.NET Core 2.0 中新增的方法，稍后我将深入介绍。

　　CreateDefaultBuilder 执行的一些操作取决于 ASP.NET Core 应用程序在哪个环境中运行。环境这一概念在 2.0 中并不新鲜，但值得简要回顾一下，因为此概念的出现频率非常高。

　　使用 IConfiguration 和 IConfigurationBuilder 对象时，请务必记住提供程序的添加顺序。后添加的提供程序可能会重写先添加的提供程序的设置。因此，不妨先添加常见的基础提供程序，然后再添加可能会重写一些设置的环境专属提供程序。

　　ASP.NET Core 中的配置设置是分层的。例如，在新建的项目中，appsettings.json（见图 3）包含一个顶层元素 Logging，其下包含子设置。这些设置指明要记录的消息的最低优先级（通过“LogLevel”设置），以及是否应在记录消息的同时记录应用程序的逻辑范围（通过 IncludeScopes）。

　　若要检索像这样的嵌套设置，可以使用 IConfiguration.GetSection 方法，检索配置的各个部分，也可以指定特定设置的完整路径（以冒号分隔）。因此，可以按如下所示，在项目中检索 Include­Scopes 的值：

　　使用环境变量定义配置设置时，环境变量名称应包含层次结构的所有级别，并且可以使用冒号 (:) 或双下划线 (__) 作为分隔符。

　　如果在调用 dotnet run 之前将环境设置为 Development，应该会发现有不少的控制台日志（这很好，因为这样对调试非常有用）。

　　相比之下，如果将环境设置为 Production，除了警告和错误之外，不会生成其他任何控制台日志（这同样也很好，因为控制台日志的速度慢，应在生产中将数量降至最低）。

　　以前，在创建 Startup 类型期间创建 IConfiguration 是很常见的做法。新增的 ConfigureAppConfiguration 方法可有效替代这种做法，因为它可以更新应用程序依赖关系注入 (DI) 容器中存储的 IConfiguration 对象，以方便日后检索，并能在应用程序生命周期的较早期提供配置设置。

　　与配置一样，ASP.NET Core 日志也可扩展。注册的各个提供程序可以记录到不同的终结点。引用 Microsoft.AspNetCore.All 可以立即获取许多提供程序。若要获取更多提供程序，请访问 .NET 开发者社区。

　　在日志配置完成且提供程序已注册后，ASP.NET Core 便会自动记录工作状况消息，以处理传入请求。还可以通过依赖关系注入请求获取 ILogger 对象，从而记录自己的诊断消息（下一部分将对此进行详细介绍）。

　　ASP.NET Core 2.0 中的 Startup.cs 没有太多变化（只是变得更简单了，因为日志和配置都已改为在 Program.cs 中设置），但我还是要简要回顾一下 Startup 类型的两个重要方法，因为它们对 ASP.NET Core 应用程序非常重要。

　　依赖关系注入：Startup 类型的 ConfigureServices 方法将服务添加到应用程序的依赖关系注入容器中。所有 ASP.NET Core 应用程序都有一个默认依赖关系注入容器，用于存储服务，以供日后使用。这样一来，服务无需与依赖它们的组件紧密耦合，即可供使用。

　　已介绍过几个这样的示例，ConfigureAppConfiguration 和 ConfigureLogging 向容器添加服务，以供日后可在应用程序中使用。在运行时，如果类型实例获得调用，那么 ASP.NET Core 会自动从依赖关系注入容器（若有）中检索对象。

　　再例如，若要从 Razor 页面记录消息，可以请求将参数形式的记录器对象获取到页面模型的构造函数中（就像 Startup 请求获取 IConfiguration 对象一样），也可以在 cshtml 中使用 @inject 语法这样做，如下所示：

　　还可以执行一些类似操作，检索 IConfiguration 对象或其他任何已注册为服务的类型。这样一来，Startup 类型、Razor 页面、控制器等与依赖关系注入容器所提供服务的依赖就不会太紧密。

　　正如本部分开头所提，在 Startup.ConfigureServices 方法中，服务被添加到依赖关系注入容器。用于创建应用程序的项目模板已在 ConfigureServices 中执行了一次调用，即 services.AddMvc。大家可能已猜到，这会注册 MVC 框架需要的服务。

　　如果注册为单一实例，每当有请求获取服务类型时，就会返回服务的单一实例；如果注册为临时实例，就会为每个请求新建一个实例。如果添加为范围内实例，将在一个 HTTP 请求的整个处理过程中使用一个服务实例。若要更深入地了解 ASP.NET Core 中的依赖关系注入，请访问bit.ly/2w7XtJI。

　　HTTP 请求处理管道和中间件：Startup 类型中的另一个重要方法是 Configure 方法。这是设置 ASP.NET Core 应用程序的核心（即 HTTP 请求处理管道）的地方。在此方法中，将注册不同的中间件，用于处理传入的 HTTP 请求，以生成响应。

　　在 Startup.Configure 中，中间件组件会被添加到 IApplicationBuilder 中，以形成处理管道。若有请求，将调用已注册的首个中间件。

　　此中间件将执行所需的任何逻辑，然后再调用管道中的下一个中间件，或在已完全处理响应的情况下返回到上一个中间件（若有），这样就可以在响应准备就绪后执行任何所需的逻辑。图 4 展示了这种调用模式，即在有请求时先依序调用中间件组件，然后再在处理完毕后逆序调用中间件组件。

　　这些中间件组件最初并不会执行多少操作，但在后续中间件运行且请求通过中间件管道返回后，它们将监视并处理异常。

　　接下来，将调用 StaticFiles 中间件，它可以提供静态文件（例如，图像或样式表），从而处理请求。如果是这样，它将暂停管道，并将控制权归还给上一个中间件，即异常处理程序。

　　如果 StaticFiles 中间件无法提供响应，它将调用下一个中间件，即 MVC 中间件。根据指定的路由选项，此中间件会尝试将请求路由到 MVC 控制器（或 Razor 页面），以实现请求履行。

　　中间件组件的注册顺序非常重要。如果 UseStaticFiles 是在 UseMvc 后面注册，应用程序会先尝试将所有请求路由到 MVC 控制器，然后再检查是否有静态文件。这可能会导致性能大大降低！ 如果管道的靠后位置上有异常处理中间件，那么它将无法处理在上一个中间件组件中出现的异常。

　　除了 .csproj、program.cs 和 startup.cs 文件之外，ASP.NET Core 项目还有一个“页面”文件夹，其中包含应用程序的 Razor 页面。Razor 页面类似于 MVC 视图，不同之处在于可以直接将请求路由到 Razor 页面，而不需要单独使用控制器。

　　这样一来，便可以简化基于页面的应用程序，并确保视图和视图模型在一起。支持页面的模型可以直接包含在 cshtml 页面中（使用 @functions 指令），也可以包含在单独的代码文件中（使用 @model 指令引用）。

　　希望本次演练能够帮助大家了解如何新建 ASP.NET Core 2.0 Web 应用程序，并很好地揭秘了新项目模板的内容。我回顾了项目内容，包括简化的 .csproj 文件、Program.cs 中的应用程序入口点和 Web 主机配置，以及 Startup.cs 中的服务和中间件注册。

　　若要更深入发掘 ASP.NET Core 的无限可能，使用其他部分模板（如 Web API 模板或部分新 SPA 模板）新建一些项目可能会有所帮助。

　　此外，不妨尝试将 ASP.NET Core 应用程序作为应用服务 Web 应用部署到 Azure，也可以将应用程序打包为 Linux 或 Windows Docker 映像。若要详细了解本文涉及的主题和更多内容，当然可以查看中的完整文档。

　　自 2004 年以来，Rousos 一直都是 .NET 团队的一员，致力于研究跟踪、安全托管、托管和最新技术 .NET Core。