1

If I had to summarize why we need middleware in .NET development in one sentence, I would say:

Middleware is a way of centralizing and standardizing cross-cutting concerns so they don’t need to be repeated in every controller or endpoint.

The mental model of middleware in ASP.NET Core looks like this:

2

where middleware runs BEFORE and also AFTER the controller.

This allows us to centralize and standardize logic instead of repeating it in every controller.

Imagine life before middleware. I would need to perform the following actions inside my controller logic:

The code in the controller would look like this:

  
    public IActionResult GetUser()
{
    try
    {
        LogRequest();//log method

        if (!IsAuthenticated()) //authentication method
            return Unauthorized();

        var result = _service.GetUser();

        AddSecurityHeaders(); //add security header in response 

        return Ok(result);
    }
    catch(Exception ex)
    {
        LogError(ex);
        return StatusCode(500);
    }
}

Now imagine we have many other controllers that also need to implement the same logic as previous controller

UserController
ProductController
OrderController
PaymentController
InvoiceController

This can lead to duplicated code, maintenance issues, and even missed logic in some controllers, such as forgetting a security check or logging.

To make it worse, as the system grows, we may need to add more features like traffic monitoring, IP blocking, caching, audit logging, and so on. Adding these changes to every controller would make maintenance extremely expensive and error-prone.

We can solve this problem by centralizing the code using middleware.

Instead of repeating logic in every controller, we create separate middleware components for each concern, such as logging, authentication, and adding security headers.

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;

    public LoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        Console.WriteLine(
            $"Request: {context.Request.Path}");

        await _next(context);
    }
}
public class AuthenticationMiddleware
{
    private readonly RequestDelegate _next;

    public AuthenticationMiddleware(
        RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (!IsAuthenticated(context))
        {
            context.Response.StatusCode = 401;
            await context.Response.WriteAsync(
                "Unauthorized");

            return;
        }

        await _next(context);
    }
}
public class SecurityHeaderMiddleware
{
    private readonly RequestDelegate _next;

    public SecurityHeaderMiddleware(
        RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        await _next(context);

        context.Response.Headers.Add(
            "X-Frame-Options",
            "DENY");
    }
}

And now, we can register our customized middleware in the program.cs

 
app.UseMiddleware<LoggingMiddleware>();

app.UseMiddleware<AuthenticationMiddleware>();

app.UseMiddleware<SecurityHeaderMiddleware>();

With this approach, we can centralize and standardize our logic. Logging and authentication are performed before the controller is called, and security headers can be added before the response is returned from the controller.

Another point I want to emphasize is built-in middleware. In my previous example, I created custom middleware for authentication, but in reality, .NET already provides built-in middleware for common concerns like this. We don’t need to reinvent the wheel — we can simply use the standard components provided by the framework.

So the pipeline should look like this:

 
app.UseAuthentication();
app.UseHttpLogging(); //this is for http logging, 
//but for application logging we need to write a customize one

Middleware gives us a clean way to centralize and standardize cross-cutting logic, making our applications easier to maintain and scale. By moving shared concerns out of controllers, we keep our codebase simpler, more consistent, and less error-prone.