ASP.NET Core middleware vs filters

There is a video about this on channel 9: ASP.NET Monsters #91: Middleware vs. Filters. To summarize the video:

https://i.stack.imgur.com/31siT.jpg

---

Middleware operate on the level of ASP.NET Core and can act on every single request that comes in to the application.

MVC filters on the other hand only run for requests that come to MVC.

So for example, if I wanted to enforce that all requests must be done over HTTPS, I would have to use a middleware for that. If I made an MVC filter that did that, users could still request e.g. static files over HTTP.

But then on the other hand something that logs request durations in MVC controllers could absolutely be an action filter.

---

The execution of middleware occurs before the MVC context becomes available in the pipeline. That is, middleware does not have access to the ActionExecutingContext or the ActionExecutedContext in the case of an ActionFilter for example. What you do have access to is the HttpContext, which will allow you to perform actions on the request as well as the response. Since model binding hasn’t occurred yet, using middleware would not be suited to running a validation function or modifying values. Middleware will also run on every request regardless of which controller or action is called.

On the other hand, filters will only run on specified actions and controllers unless you register the filter globally in the startup. Since you have full access to the context you can also access the controller and action itself.

Source and example: thetechplatform.com

---

Filter pipeline is similar to middleware pipeline in many ways, but they also have some differences that should be considered when deciding which approach to be used.

What are the similarities:

Incoming requests pass through a middleware component and outgoing responses to those requests are passing again through the same middleware when going to the client. Some filters (resource, action, and result) are also two-way, others (authorization and exception) run only once for a request, and page filters (Razor pages specific) run three times.

Middlewares can short-circuit a request by directly returning a response, instead of executing the entire middleware pipeline and not passing the request down to later middlewares. Filters can also short-circuit the filter pipeline by directly returning a response.

Middlewares are used for cross-cutting concerns (eg: logging, performance profiling or exception handling). Filters are also used for dealing with cross-cutting concerns.

What are the differences:

A middleware can run for all requests while filters will only run for requests that reach the EndpointMiddleware and execute an action from an API Controller or a Razor Page.

Filters have access to MVC components (eg: ModelState or IActionResults). Middleware works at a lower level compared to filters and is independent of MVC and Razor Pages, so it can't use any of those related components.

Filters are designed to be applied to a subset of requests, not to all of them. For instance, we can apply a filter on a single controller or a single Razor Page. In contrast, middlewares don't have this kind of design.

So, when trying to figure out what should use: filters or middlewares, the answer should come from the above comparison. As a TL;DR:

middleware is the more general concept, which operates on lower-level abstractions like HttpContext, so can be applied in a wider area. Also we should be aware of the fact that the functionality we need to implement has no MVC-specific requirements

filters can enable us the usage of MVC-constructs and can be used for implementing custom and specific behavior for some MVC actions. It is not so general as middleware.

---