Net Core教程

ASP.NET Core 管道再探

本文主要是介绍ASP.NET Core 管道再探,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

ASP.NET Core 管道再探

几乎任何服务器端处理环境都有自己的直通组件管道,用于检查、重路由或修改传入请求和传出响应。经典 ASP.NET 围绕 HTTP 模块理念进行排列,而 ASP.NET Core 采用基于中间件组件的更现代的体系结构。最终目的是相同的 - 允许可配置的外部模块以请求(以及稍后的响应)在服务器环境中传递的方式进行干预。中间件组件的主要目的是以某种方式改变和筛选数据流(在某些特定情况下,只是使请求短路,停止任何进一步的处理)。

ASP.NET Core 管道自框架 1.0 版发布以来几乎没有变化,但即将发布的 ASP.NET Core 3.0 邀请了一些关于当前体系结构的评论,这些评论在很大程度上被忽略了。因此,在本文中,我将重新讨论 ASP.NET Core 运行时管道的整体功能,并着重介绍 HTTP 终结点的角色和可能的实现。

适用于 Web 后端的 ASP.NET Core
特别是在过去几年,构建前端和后端完全解耦的 Web 应用程序已经变得相当普遍。因此,大多数 ASP.NET Core 项目现在都是简单的没有 UI 的 Web API 项目,仅为单页面和/或移动应用程序提供 HTTP 外观,大多数情况下,这些应用通过 Angular、React、Vue 及其移动对等项构建而成。

当你意识到这一点,将出现一个问题:在不使用任何 Razor 工具的应用程序中,绑定到 MVC 应用程序模型是否仍有意义?MVC 模型并不是免费的,事实上,在某种程度上,一旦停止使用控制器来提供操作结果,它甚至可能不是最轻量级的选项。进一步追问:如果大部分 ASP.NET Core 代码编写只是为了返回 JSON 有效负载,那么操作结果概念本身是否绝对必要?

带着这些想法,让我们回顾一下 ASP.NET Core 管道和中间件组件的内部结构,以及可以在启动期间绑定到的内置运行时服务列表。

启动类
在任何 ASP.NET Core 应用程序中,一个类被指定为应用程序引导程序。大多数情况下,此类采用名称“Startup”。该类在 Web 主机配置中声明为启动类,Web 主机通过反射实例化并调用该类。该类可以有两种方法 - ConfigureServices(可选)和 Configure。在第一个方法中,你将接收当前(默认)运行时服务列表,并需要添加更多服务来为实际应用程序逻辑做准备。在 Configure 方法中,为默认服务和显式请求支持应用程序的服务进行配置。

Configure 方法接收至少一个应用程序生成器类实例。可以将此实例视为传递给代码的 ASP.NET 运行时管道的工作实例,以便根据需要进行配置。一旦 Configure 方法返回,管道工作流将配置完毕,并用于执行从连接的客户端发送的任何进一步请求。图 1 提供了 Startup 类的 Configure 方法的实现示例。

图 1 Startup 类中 Configure 方法的基本示例

C#

public void Configure(IApplicationBuilder app)
{
  app.Use(async (context, nextMiddleware) =>
  {
    await context.Response.WriteAsync("BEFORE");
    await nextMiddleware();  
    await context.Response.WriteAsync("AFTER");
  });
  app.Run(async (context) =>
  {
    var obj = new SomeWork();
    await context
      .Response
      .WriteAsync("<h1 style='color:red;'>" +
                   obj.SomeMethod() +
                  "</h1>");
  });
}

Use 扩展方法是用于将中间件代码添加到其他空管道工作流的主要方法。注意,添加的中间件越多,服务器需要执行更多的工作来满足任何传入请求。最小的是管道,最快的是客户端至第一字节的时间 (TTFB)。

可以使用 lambdas 或临时中间件类向管道添加中间件代码。这完全由你来决定:lambda 更直接,但类(最好是一些扩展方法)将使整个过程更易于阅读和维护。中间件代码获取请求的 HTTP 上下文和对管道中下一个中间件的引用(如果有的话)。图 2 显示了各种中间件组件链接在一起的总体视图。

ASP.NET Core 运行时管道

在这里插入图片描述
图 2 ASP.NET Core 运行时管道

每个中间件组件都有两次机会介入正在进行的请求的生命周期。它可以预先处理从先前注册运行的组件链接收到的请求,然后它会被链中的下一个组件取代。当链中的最后一个组件有机会预先处理请求时,请求会被传递给终止中间件,以便进行实际处理,目的是生成具体输出。之后,组件链按相反顺序返回,如图 2 所示,每个中间件都有第二次处理的机会 - 不过,这一次将是后处理操作。在图 1 代码中,预处理代码与后处理代码的分割线为:

C#

await nextMiddleware();

终止中间件
在图 2 所示的体系结构中,关键是终止中间件的角色,它是 Configure 方法底部的代码,用于终止链并处理请求。所有演示 ASP.NET Core 应用程序都有一个终止的 lambda,如下所示:

C#

app.Run(async (context) => { ... };
lambda 接收 HttpContext 对象,并在应用程序上下文中执行它应执行的任何操作。

实际上,有意不生成到下一个组件的中间件组件将终止链,进而导致响应被发送到请求的客户端。UseStaticFiles 中间件就是一个很好的例子,它在指定的 Web 根文件夹下提供静态资源,并终止请求。另一个示例是 UseRewriter,它可以命令客户端重定向到新 URL。在没有终止中间件的情况下,请求很难在客户端上产生一些可见输出,尽管响应仍然通过运行中间件(例如,通过添加 HTTP 标头或响应 cookie)以修改后的形式发送。

还有两个专用的中间件工具也可用于短路请求:app.Map 和 app.MapWhen。前者检查请求路径是否匹配参数并运行自己的终止中间件,如下所示:

C#

app.Map("/now", now =>
{
  now.Run(async context =>
  {
    var time = DateTime.UtcNow.ToString("HH:mm:ss");
    await context
      .Response
      .WriteAsync(time);
  });
});

而后者仅在验证了指定布尔条件后才运行自己的终止中间件。布尔条件来自接受 HttpContext 的函数计算。图 3**** 中的代码提供了一个非常精简的小型 Web API,它仅为单个终结点提供服务,并且在没有任何类似于控制器类项的情况下执行该操作。

图 3 极小型 ASP.NET Core Web API

C#

public void Configure(IApplicationBuilder app,
                      ICountryRepository country)
{
  app.Map("/country", countryApp =>
  {
    countryApp.Run(async (context) =>
    {
      var query = context.Request.Query["q"];
      var list = country.AllBy(query).ToList();
      var json = JsonConvert.SerializeObject(list);
      await context.Response.WriteAsync(json);
    });
  });
  // Work as a catch-all
  app.Run(async (context) =>
  {
    await context.Response.WriteAsync("Invalid call");
  }
});

如果 URL 匹配 /country,终止中间件将从查询字符串中读取一个参数,并安排对存储库的调用,以获得匹配国家/地区列表。然后,对列表对象以 JSON 格式直接手动序列化到输出流。通过添加一些其他映射路由,你甚至可以扩展 Web API。再简单不过了。

MVC 怎么样?
在 ASP.NET Core 中,整个 MVC 机制作为黑盒运行时服务提供。只需绑定到 ConfigureServices 方法中的服务,并在 Configure 方法中配置其路由,如下面的代码所示:

C#

public void ConfigureServices(IServiceCollection services)
{
  // Bind to the MVC machinery
  services.AddMvc();
}
public void Configure(IApplicationBuilder app)
{
  // Use the MVC machinery with default route
  app.UseMvcWithDefaultRoute();
  // (As an alternative) Use the MVC machinery with attribute routing
  app.UseMvc();
}

此时,如果你打算提供 HTML,欢迎填充常用的 Controllers 文件夹,甚至 Views 文件夹。注意在 ASP.NET Core 还可以使用 POCO 控制器,它是简单的 C# 类,经修饰后可以被识别为控制器,并与 HTTP 上下文断开连接。

MVC 机制是终止中间件的另一个很好的示例。一旦请求被 MVC 中间件捕获,一切都在它的控制之下,管道会突然终止。

有趣的是,MVC 机制在内部运行自己的自定义管道。它不以中间件为中心,但它仍然是一个完整的运行时管道,控制请求如何路由到控制器操作方法,并最终将生成的操作结果呈现到输出流。MVC 管道由在各个控制器方法前后运行的各种类型的操作筛选器(操作名称选择器、授权筛选器、异常处理程序、自定义操作结果管理器)组成。在 ASP.NET Core 中,内容协商也隐藏在运行时管道中。

从更深刻的角度来看,整个 ASP.NET MVC 机制看起来就像是被固定在最新的、经重新设计的、以中间件为中心的 ASP.NET Core 管道的上方。就像 ASP.NET Core 管道和 MVC 机制是不同类型的实体,只是以某种方式连接在一起。总体情况与 MVC 被固定在现已被摒弃的 Web 窗体运行时之上的方式没有太大不同。实际上,在该上下文中,如果处理请求无法与物理文件匹配(很可能是 ASPX 文件),MVC 就会通过专用的 HTTP 处理程序启动。

这有问题吗?很可能没有。也许问题还没出现!

将 SignalR 置于循环中
将 SignalR 添加到 ASP.NET Core 应用程序时,需要做的就是创建一个中心类来公开终结点。有趣的是中心类可能与控制器完全不相关。不需要 MVC 来运行 SignalR,但中心类的行为类似于外部请求的前端控制器。从中心类公开的方法可以执行任何工作 - 甚至与框架的跨应用通知性质无关的工作,如图 4 所示。

图 4 从中心类公开方法

C#

public class SomeHub : Hub
{
  public void Method1()
  {
    // Some logic
    ...
    Clients.All.SendAsync("...");
  }
  public void Method2()
  {
    // Some other logic
    ...
    Clients.All.SendAsync("...");
  }
}

能看到图片吗?

SignalR 中心类可以被视为一个控制器类,不需要整个 MVC 机制,非常适合无 UI(或者更确切地说,是 Razor)响应。

将 gRPC 置于循环中
在 3.0 版本中,ASP.NET Core 还提供了对 gRPC 框架的本机支持。该框架设计为与 RPC 准则一起使用,是围绕接口定义语言的一层代码,接口定义语言完全定义终结点,并且能够使用 HTTP/2 上的 Protobuf 二进制序列化触发连接方之间的通信。从 ASP.NET Core 3.0 角度来看,gRPC 还是另一个可调用外观,可以进行服务器端计算并返回值。下面介绍了如何启用 ASP.NET Core 服务器应用程序以支持 gRPC:

C#

public void ConfigureServices(IServiceCollection services)
{
  services.AddGrpc();
}
public void Configure(IApplicationBuilder app)
{
  app.UseRouting(routes =>
    {
      routes.MapGrpcService<GreeterService>();
    });
}

另请注意全局路由的使用,以使应用程序支持没有 MVC 机制的路由。可以将 UseRouting 视为定义 app.Map 中间件块的一种更结构化的方法。

前面代码的净效果是支持从客户端应用程序到映射服务的 RPC 样式调用,即 Greeter­Service 类。有趣的是,GreeterService 类在概念上等同于 POCO 控制器,只不过它不需要被识别为控制器类,如下所示:

C#

public class GreeterService : Greeter.GreeterBase
{
  public GreeterService(ILogger<GreeterService> logger)
  {
  }
}

基类(GreeterBase 是一个封装在静态类中的抽象类)包含执行请求/响应通信所需的管道。gRPC 服务类与 ASP.Net Core 基础结构完全集成,可以注入外部引用。

底线
特别是随着 ASP.NET Core 3.0 的发布,将会出现另外两种情况,在这些情况下,使用无 MVC 的控制器样式外观将会很有帮助。SignalR 有一个中心类,gRPC 有一个服务类,但关键是它们在概念上是相同的,必须在不同的场景以不同方式实现这些类。MVC 机制已或多或少被移植到 ASP.NET Core,因为它最初是为经典 ASP.NET 设计的,并围绕控制器和操作结果维护自己的内部管道。与此同时,随着 ASP.NET Core 越来越广泛地被用作普通后端服务提供程序(不支持视图),对 HTTP 终结点可能统一的 RPC 样式外观的需求也在增长。

这篇关于ASP.NET Core 管道再探的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!