NET 核心中间件与过滤器

在阅读了 ASP.NET Core 中间件之后，我对什么时候应该使用过滤器和什么时候应该使用中间件感到困惑，因为它们似乎达到了同样的目的。 什么时候应该使用中间件而不是过滤器？

63804 次浏览
小开

中间件在 ASP.NET 核心级别上运行，可以处理进入应用程序的每一个请求。

另一方面，MVC 过滤器只运行来自 MVC 的请求。

例如，如果我想强制所有请求都必须通过 HTTPS 完成，我就必须使用一个中间件。如果我做了一个 MVC 过滤器，用户仍然可以通过 HTTP 请求静态文件。

但另一方面，在 MVC 控制器中记录请求持续时间的东西绝对可以是动作过滤器。

小开
最佳答案

在9频道 NET 怪兽 # 91: 中间件 vs 过滤器有一个关于这个的视频。视频总结如下:

请求的执行开始了，我们有一个中间件，另一个中间件，把它想象成“娃娃里的俄罗斯娃娃”，最终路由中间件启动，然后请求进入 MVC 管道。 enter image description here 因此，如果您不需要 MVC 的上下文(假设您关心的是流和执行，比如响应头部的一些预路由机制等) ，那么使用 中间件。
但是，如果您需要 MVC 的上下文，并且希望对操作进行操作，那么可以使用 过滤器。

小开

middleware的执行发生在 MVC 上下文在管道中变得可用之前。也就是说，在 ActionFilter 的情况下，例如，middleware不能访问 ActionExecutingContext或 ActionExecutedContext。您可以访问的是 HttpContext，它允许您对请求和响应执行操作。由于模型绑定尚未发生，因此使用中间件不适合运行验证函数或修改值。无论调用哪个控制器或操作，Middleware也将在每个请求上运行。

另一方面，除非在启动时全局注册过滤器，否则 filters只能在指定的操作和控制器上运行。因为您可以完全访问上下文，所以还可以访问控制器和操作本身。

来源和例子: Thetechplatform.com

小开

过滤器管道在许多方面与中间件管道相似，但它们也有一些差异，在决定使用哪种方法时应该考虑这些差异。

有什么相似之处:

  • 传入请求通过中间件组件传递，对这些请求的传出响应在传递到客户机时再次通过相同的中间件传递。有些过滤器(资源、操作和结果)也是双向的，其他过滤器(授权和异常)只对请求运行一次，页过滤器(特定于 Razor 页面)运行三次。
  • 中间件可以通过直接返回响应来缩短请求，而不必执行整个中间件管道，也不必将请求传递给以后的中间件。过滤器还可以通过直接返回响应使过滤器管道短路。
  • 中间件用于横切关注点(例如: 日志记录、性能分析或异常处理)。过滤器还用于处理横切关注点。

有什么不同:

  • 中间件可以运行所有请求，而过滤器只运行到达 EndpointMiddleware的请求，并执行来自 API 控制器或 Razor Page 的操作。
  • 过滤器可以访问 MVC 组件(例如: ModelState或 IActionResults)。与过滤器相比，中间件的工作级别较低，并且独立于 MVC 和 Razor Pages，因此它不能使用任何相关组件。
  • 过滤器被设计为应用于请求的子集，而不是所有请求。例如，我们可以在单个控制器或单个 Razor Page 上应用过滤器。相比之下，中间件没有这种设计。

因此，当试图找出应该使用什么: 过滤器或中间件时，答案应该来自上面的比较。 作为 TL; DR:

  • 中间件是一个更加通用的概念，它运行在像 HttpContext这样的底层抽象上，因此可以应用于更广泛的领域。我们还应该意识到这样一个事实，即我们需要实现的功能没有 MVC 特定的需求
  • 过滤器可以使我们使用 MVC 构造，并且可以用于实现一些 MVC 操作的自定义和特定行为。它不像中间件那样通用。

提交答案