【发布时间】：2017-07-23 19:01:14
【问题描述】：
在阅读了 ASP.NET Core 中间件之后，我对何时应该使用过滤器以及何时应该使用中间件感到困惑，因为它们似乎可以实现相同的目标。 什么时候应该使用中间件而不是过滤器？
【问题讨论】：
【发布时间】：2017-07-23 19:01:14
【问题描述】：
过滤器管道在许多方面类似于中间件管道，但它们也有一些差异，在决定使用哪种方法时应该考虑。
有什么相似之处：
- 传入的请求通过中间件组件，而对这些请求的传出响应在到达客户端时再次通过相同的中间件。一些过滤器（资源、操作和结果）也是双向的，其他过滤器（授权和异常）仅针对请求运行一次，而页面过滤器（特定于 Razor 页面）运行三次。
- 中间件可以通过直接返回响应来缩短请求，而不是执行整个中间件管道并且不将请求传递给后面的中间件。过滤器还可以通过直接返回响应来使过滤器管道短路。
- 中间件用于横切关注点（例如：日志记录、性能分析或异常处理）。过滤器也用于处理横切关注点。
有什么区别：
- 中间件可以针对所有请求运行，而过滤器仅针对到达
EndpointMiddleware并从 API 控制器或 Razor 页面执行操作的请求运行。 - 过滤器可以访问 MVC 组件（例如：
ModelState或IActionResults）。与过滤器相比，中间件的工作级别较低，并且独立于 MVC 和 Razor 页面，因此它不能使用任何这些相关组件。 - 过滤器旨在应用于请求的子集，而不是所有请求。例如，我们可以在单个控制器或单个 Razor 页面上应用过滤器。相比之下，中间件就没有这种设计。
所以，当试图弄清楚应该使用什么：过滤器或中间件时，答案应该来自上面的比较。 作为 TL；DR：
- 中间件是一个更笼统的概念，它对
HttpContext这样的低层抽象进行操作，因此可以应用到更广泛的领域。 我们还应该意识到，我们需要实现的功能没有特定于 MVC 的要求 - 过滤器可以让我们使用 MVC 结构，并且可以用于为某些 MVC 操作实现自定义和特定行为。 它不像中间件那么通用。
【讨论】：
第 9 频道有一个关于此的视频：ASP.NET Monsters #91: Middleware vs. Filters。总结视频：
请求的执行开始，我们有一个中间件，另一个中间件，把它想象成“玩偶里面的俄罗斯玩偶”，最终路由中间件启动，然后请求进入 MVC 管道。
因此，如果您不需要 MVC 的上下文（假设您关心流程和执行，例如响应标头一些预路由机制等），那么请使用 中间件。
但是，如果您需要 MVC 的上下文并且想要针对操作进行操作，那么请使用 过滤器。
【讨论】：
-
所以，如果我有逻辑我想在每个请求（例如日志记录）上运行，只有其中一些与 MVC 相关，我会将它放在中间件中，然后让过滤器处理程序执行任何特定的操作它可能需要逻辑，然后重新抛出到中间件？
middleware 的执行发生在 MVC 上下文在管道中可用之前。也就是说，在 ActionFilter 的情况下，middleware 无权访问 ActionExecutingContext 或 ActionExecutedContext。您可以访问的是HttpContext，它允许您对请求和响应执行操作。由于尚未发生模型绑定，因此使用中间件不适合运行验证函数或修改值。 Middleware 也将在每个请求上运行，无论调用哪个控制器或操作。
另一方面，filters 只会在指定的操作和控制器上运行，除非您在启动时全局注册过滤器。由于您可以完全访问上下文，因此您还可以访问控制器和操作本身。
来源和例子：dotnetcultist.com
【讨论】：
-
你的回答真的让我明白了一些事情。谢谢。
中间件在 ASP.NET Core 级别上运行，可以对进入应用程序的每个请求进行操作。
另一方面，MVC 过滤器仅针对到达 MVC 的请求运行。
例如，如果我想强制所有请求必须通过 HTTPS 完成，我将不得不为此使用中间件。如果我做了一个 MVC 过滤器，用户仍然可以请求例如HTTP 上的静态文件。
但另一方面，在 MVC 控制器中记录请求持续时间的东西绝对可能是一个动作过滤器。
【讨论】：