Architecture

When building modern web applications in ASP.NET Core, we constantly deal with “cross-cutting concerns.” These are the essential but repetitive tasks that cut across our application’s features: logging, authentication, authorization, caching, and error handling. The framework gives us two powerful tools for this job: Middleware and Filters.

While both can solve similar problems, they operate at different levels of the application stack. A common point of confusion for developers is choosing the right tool. Let me be direct: for truly global, application-wide cross-cutting concerns, Middleware is almost always the superior choice.

This post will break down why Middleware holds a strategic advantage over Filters for these scenarios and clarify when Filters still have their essential place.

Understanding the Players: The Pipeline is Everything

The key to this discussion is understanding where Middleware and Filters live within the ASP.NET Core request processing pipeline.

What is Middleware?

Think of Middleware as a series of components chained together to form the fundamental request and response pipeline. Each piece of middleware inspects an incoming HttpContext, performs an action, and then either passes the request to the next component in the chain or short-circuits the process by generating a response itself.

It’s low-level, efficient, and completely agnostic of what will ultimately handle the request. It doesn’t know about MVC controllers, …

I’ll never forget the first time I got called at midnight for a performance issue that was my fault. A dashboard in our SaaS app was timing out, and customers were angry. After hours of digging, the culprit was a monster LINQ query generated by Entity Framework Core. It was trying to be clever, but the generated SQL was a performance disaster.

We rewrote that one query using raw SQL with Dapper, and boom: the endpoint went from taking 15 seconds to under 200 milliseconds.

That experience taught me a crucial lesson. The endless debate about EF Core vs. Dapper is asking the wrong question. It’s not about which one is “better.” It’s about knowing which tool to grab for the job at hand. This isn’t about benchmarks; it’s about shipping features that are fast and easy to maintain.

Let’s break down how I decide in the real world.

EF Core: Your Go-To for Business Logic

I start every new project with EF Core. The productivity boost is just too massive to ignore. It shines when your main job is translating complex business rules into code.

Modeling Your Business, Not Just Tables

When your app has real business rules, you want your code to reflect that. EF Core’s mapping for C# objects (POCOs) is fantastic. Features like navigation properties, value objects, and owned types let you build a rich domain model that makes sense.

Think about an Order class. With EF Core, it’s clean and reflects the business.

public class Order
{ …