dotnet学习笔记-专题06-过滤器和中间件-01

1. 基本概念

在ASP.NET Core中，中间件和过滤器都是处理HTTP请求的重要组件，但它们在应用中的位置、作用范围以及使用方式有所不同。

1.1 中间件和过滤器的区别

1.1.1 中间件

1. 位置与作用范围：中间件位于ASP.NET Core应用程序请求处理管道的核心位置，它可以处理进入应用程序的每一个HTTP请求和响应。中间件按照定义的顺序执行，每个中间件都有机会处理请求，或者将请求传递给管道中的下一个中间件。这意味着中间件具有更广泛的控制能力，可以对整个应用程序的所有请求进行拦截和处理。

2. 功能：中间件通常用于执行跨-cutting关注点的任务，比如错误处理、日志记录、身份验证、路由、静态文件服务等。它们可以读取、修改请求和响应对象，或者短路请求链，直接向客户端发送响应。

3. 实现方式：中间件通常由一个或多个委托（ Delegate ）组成，这些委托会在应用程序启动时被添加到请求处理管道中。可以通过实现IMiddleware接口或使用中间件工厂方法来创建自定义中间件。

1.1.2 过滤器

1. 位置与作用范围：过滤器则更加专注于MVC应用程序内部，特别是针对控制器和操作方法的请求处理流程。它们只在MVC处理请求的特定阶段生效，不会影响到非MVC路径的请求。

2. 类型与功能：ASP.NET Core MVC支持多种类型的过滤器，包括但不限于：

   • IResourceFilter 和 IAsyncResourceFilter：最早和最晚执行的过滤器，用于资源级别的操作。
   • IActionFilter 和 IAsyncActionFilter：在执行操作方法前后运行，可以用来修改操作参数或结果。
   • IAuthorizationFilter 和 IAsyncAuthorizationFilter：用于处理授权逻辑。
   • IExceptionFilter 和 IAsyncExceptionFilter：捕获并处理操作方法中抛出的异常。
   • IResultFilter 和 IAsyncResultFilter：在执行操作结果之前和之后运行，可以用来修改结果或响应。

3. 实现方式：过滤器可以通过实现相应的接口并应用特性（Attribute）到控制器或操作方法上来定义。也可以通过在Startup.cs的ConfigureServices方法中注册全局过滤器。

总结来说，中间件提供了对整个应用程序请求处理流程的低级控制，而过滤器则更加专注于MVC框架内的特定操作和控制器，提供了一种更细粒度的处理和干预方式。两者结合使用，可以构建出既强大又灵活的应用程序请求处理架构。

1.2 Asp.Net Core中有哪些内置过滤器，它们的调用顺序是怎样的

在ASP.NET MVC（包括ASP.NET Core MVC）框架中，过滤器是用来在特定的执行阶段插入自定义逻辑的组件。过滤器主要分为以下几种类型，并按照特定的顺序执行：

1. 授权过滤器 (Authorization Filters): 这些过滤器首先执行，用于检查用户是否有权限执行接下来的操作。例如，可以在这里实现角色检查或者JWT令牌验证。

2. 资源过滤器 (Resource Filters): 包括 IResourceFilter 和 IAsyncResourceFilter，它们在授权过滤器之后但在操作方法执行前运行。这些过滤器可用于执行一些早期或晚期的资源处理逻辑。

3. 操作过滤器 (Action Filters): 分为 IActionFilter 和 IAsyncActionFilter。操作过滤器在资源过滤器之后，在操作方法执行前后分别调用。它们常用于日志记录、修改操作参数或结果等。

   • OnActionExecuting: 在操作方法执行前调用。
   • OnActionExecuted: 在操作方法执行后调用，无论操作是否成功。

4. 结果过滤器 (Result Filters): 包括 IResultFilter 和 IAsyncResultFilter。这些过滤器在操作方法执行完毕且操作结果已知后调用，但在实际的结果执行之前或之后。

   • OnResultExecuting: 在操作结果执行前调用。
   • OnResultExecuted: 在操作结果执行后调用。

5. 异常过滤器 (Exception Filters): 如果在前面任何阶段发生未处理异常，IExceptionFilter 或 IAsyncExceptionFilter 将被执行，用于捕获和处理这些异常。如果在Action过滤器或Result过滤器中抛出了异常，也会执行这里的逻辑。

注意，如果在Action过滤器中抛出了异常，将不会执行Result过滤器，而是直接跳转到异常过滤器。此外，如果在同一个阶段注册了多个过滤器（例如，多个操作过滤器），它们将按照注册顺序执行。

过滤器可以在全局、控制器级别或操作方法级别应用，遵循的原则是：

• 控制器上的过滤器优先于方法上的过滤器。
• 同一级别的过滤器按照注册顺序执行。

这个顺序确保了从请求验证到最终响应生成的流程中，每个阶段都可以插入定制化的处理逻辑。

1.3 Asp.Net Core中有哪些中间件，它们的调用顺序是怎样的

1.3.1 内置中间件

ASP.NET Core 提供了一系列内置的中间件，这些中间件覆盖了从基本的请求处理到高级功能的广泛需求。以下是一些常用的内置中间件：

1. Static Files：用于提供网站的静态资源，如CSS、JavaScript和图像文件。

2. Routing：路由中间件，用于根据URL映射到具体的控制器和操作方法。

3. Authentication：身份验证中间件，支持多种认证方案，如Cookie、Bearer Tokens、OAuth等。

4. Authorization：授权中间件，用于控制对资源的访问权限。

5. Session：会话中间件，提供跨请求的数据存储支持。

6. Cors：跨源资源共享（CORS）中间件，允许服务器指定哪些来源的请求可以访问其资源。

7. Forwarded Headers：转发标头中间件，处理代理服务器和负载均衡器设置的HTTP标头。

8. Hsts：HTTP严格传输安全（HSTS）中间件，强制浏览器通过HTTPS与服务器通信。

9. Https Redirection：HTTPS重定向中间件，自动将HTTP请求重定向到HTTPS。

10. Response Caching：响应缓存中间件，用于缓存和重用常见的响应以提高性能。

11. Compression：压缩中间件，用于压缩HTTP响应体，减少网络传输量。

12. Developer Exception Page：开发者异常页面中间件，在开发环境中显示详细的错误信息。

13. ExceptionHandler：异常处理中间件，用于统一处理未被捕获的异常并返回友好的错误响应。

14. UseStatusCodePages：状态码页面中间件，自定义HTTP状态码页面。

15. Swagger / OpenAPI：虽然不是完全内置，但通过NuGet包可轻松集成，用于生成RESTful API的文档。

除了这些内置中间件，ASP.NET Core还支持开发自定义中间件，以满足特定应用程序的需求。自定义中间件可以通过实现IMiddleware接口或使用Lambda表达式定义，来插入到请求处理管道中，实现高度定制化的功能处理。

1.3.2 调用顺序

ASP.NET Core 中内置中间件的调用顺序直接取决于你在 Startup.cs 文件的 Configure 方法中添加它们的顺序。当你使用 app.UseXXX 方法添加中间件时，它们会按照代码中从上到下的顺序被添加到请求处理管道中。

例如，如果你有以下的配置：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseMiddleware<CustomMiddleware>();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

中间件的调用顺序将是：

1. UseRouting: 配置路由相关的服务，这是处理路由的第一步，用于确定请求的终结点。
2. UseAuthentication: 应用身份验证逻辑，尝试验证请求的身份。
3. UseAuthorization: 应用授权逻辑，判断已认证的用户是否有权限访问请求的资源。
4. UseMiddleware<CustomMiddleware>: 自定义中间件，按照你的逻辑执行。
5. UseEndpoints: 配置终结点，这里是映射MVC控制器和操作方法或其他终结点，是管道中的最后一个环节，负责将请求分发到具体的处理程序。

请求会从上到下依次经过这些中间件，每个中间件可以选择是否将请求传递给管道中的下一个中间件。如果调用了 next 函数（或者在Lambda表达式中为 await next.Invoke()），控制权就会传递给下一个中间件。响应时，流程会逆序返回，让每个中间件有机会处理响应。

因此，定义中间件的顺序对于安全性、性能和功能的实现至关重要。例如，身份验证和授权中间件通常需要放在处理具体请求逻辑的中间件之前。

1.4 使用中间件还是过滤器？如何选择

在Web开发中，过滤器（Filters）和中间件（Middleware）都是用于处理进入应用程序的HTTP请求和响应的组件，但它们在使用场景和功能定位上有所不同。

使用过滤器的情景：

1. 细粒度操作控制：当你需要对特定的控制器或动作方法执行前后的处理逻辑进行控制时，如身份验证、授权、日志记录、修改模型绑定的输入或输出等，使用操作过滤器更为合适。

2. 特定请求或响应处理：如果你的处理逻辑只与某个具体操作相关，例如格式化输出、异常处理等，使用操作过滤器或结果过滤器可以针对性地处理这些需求。

3. 安全和认证：在需要对用户访问权限进行细致控制时，如基于角色的访问控制（RBAC），授权过滤器是非常有用的工具。

使用中间件的情景：

1. 全局处理逻辑：当需要对所有进入应用的请求或响应进行统一处理时，比如跨域请求（CORS）设置、请求日志记录、错误处理、请求管道的初始化和终止等，中间件是更好的选择。

2. 链式处理：中间件可以链接在一起形成请求处理管道，每个中间件可以决定是否将请求传递给管道中的下一个中间件，这使得它们非常适合执行一系列连续的处理步骤。

3. 性能监控和优化：对于需要在整个应用层面监控请求性能或执行初步请求验证（如检查请求头）的场景，中间件提供了一个全局的介入点。

简而言之，过滤器更适合于处理与具体操作相关的细节逻辑，而中间件则更适用于全局性的、跨越多个控制器或操作的处理逻辑。 在设计应用程序架构时，理解两者之间的区别并合理搭配使用，可以有效提升应用的灵活性和可维护性。