课堂网站开发,建站报价表,他达拉非片,珠海建站论坛几乎任何服务器端处理环境都有自己的直通组件管道#xff0c;用于检查、重路由或修改传入请求和传出响应。经典 ASP.NET 围绕 HTTP 模块理念进行排列#xff0c;而 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 方法的基本示例Use 扩展方法是用于将中间件代码添加到其他空管道工作流的主要方法。注意添加的中间件越多服务器需要执行更多的工作来满足任何传入请求。最小的是管道最快的是客户端至第一字节的时间 (TTFB)。可以使用 lambdas 或临时中间件类向管道添加中间件代码。这完全由你来决定lambda 更直接但类最好是一些扩展方法将使整个过程更易于阅读和维护。中间件代码获取请求的 HTTP 上下文和对管道中下一个中间件的引用如果有的话。图 2 显示了各种中间件组件链接在一起的总体视图。图 2 ASP.NET Core 运行时管道每个中间件组件都有两次机会介入正在进行的请求的生命周期。它可以预先处理从先前注册运行的组件链接收到的请求然后它会被链中的下一个组件取代。当链中的最后一个组件有机会预先处理请求时请求会被传递给终止中间件以便进行实际处理目的是生成具体输出。之后组件链按相反顺序返回如图 2 所示每个中间件都有第二次处理的机会 - 不过这一次将是后处理操作。在图 1 代码中预处理代码与后处理代码的分割线为终止中间件在图 2 所示的体系结构中关键是终止中间件的角色它是 Configure 方法底部的代码用于终止链并处理请求。所有演示 ASP.NET Core 应用程序都有一个终止的 lambda如下所示lambda 接收 HttpContext 对象并在应用程序上下文中执行它应执行的任何操作。实际上有意不生成到下一个组件的中间件组件将终止链进而导致响应被发送到请求的客户端。UseStaticFiles 中间件就是一个很好的例子它在指定的 Web 根文件夹下提供静态资源并终止请求。另一个示例是 UseRewriter它可以命令客户端重定向到新 URL。在没有终止中间件的情况下请求很难在客户端上产生一些可见输出尽管响应仍然通过运行中间件例如通过添加 HTTP 标头或响应 cookie以修改后的形式发送。还有两个专用的中间件工具也可用于短路请求app.Map 和 app.MapWhen。前者检查请求路径是否匹配参数并运行自己的终止中间件如下所示而后者仅在验证了指定布尔条件后才运行自己的终止中间件。布尔条件来自接受 HttpContext 的函数计算。图 3 中的代码提供了一个非常精简的小型 Web API它仅为单个终结点提供服务并且在没有任何类似于控制器类项的情况下执行该操作。图 3 极小型 ASP.NET Core Web API如果 URL 匹配 /country终止中间件将从查询字符串中读取一个参数并安排对存储库的调用以获得匹配国家/地区列表。然后对列表对象以 JSON 格式直接手动序列化到输出流。通过添加一些其他映射路由你甚至可以扩展 Web API。再简单不过了。MVC 怎么样在 ASP.NET Core 中整个 MVC 机制作为黑盒运行时服务提供。只需绑定到 ConfigureServices 方法中的服务并在 Configure 方法中配置其路由如下面的代码所示此时如果你打算提供 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 从中心类公开方法能看到图片吗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另请注意全局路由的使用以使应用程序支持没有 MVC 机制的路由。可以将 UseRouting 视为定义 app.Map 中间件块的一种更结构化的方法。前面代码的净效果是支持从客户端应用程序到映射服务的 RPC 样式调用即 GreeterService 类。有趣的是GreeterService 类在概念上等同于 POCO 控制器只不过它不需要被识别为控制器类如下所示基类GreeterBase 是一个封装在静态类中的抽象类包含执行请求/响应通信所需的管道。gRPC 服务类与 ASP.Net Core 基础结构完全集成可以注入外部引用。底线特别是随着 ASP.NET Core 3.0 的发布将会出现另外两种情况在这些情况下使用无 MVC 的控制器样式外观将会很有帮助。SignalR 有一个中心类gRPC 有一个服务类但关键是它们在概念上是相同的必须在不同的场景以不同方式实现这些类。MVC 机制已或多或少被移植到 ASP.NET Core因为它最初是为经典 ASP.NET 设计的并围绕控制器和操作结果维护自己的内部管道。与此同时随着 ASP.NET Core 越来越广泛地被用作普通后端服务提供程序不支持视图对 HTTP 终结点可能统一的 RPC 样式外观的需求也在增长。原文地址https://msdn.microsoft.com/zh-cn/magazine/mt833464.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
