For years, the MediatR package has been a default inclusion in almost every new .NET project template. It is frequently hailed as the gold standard for decoupling controllers or minimal APIs from business logic and implementing Clean Architecture or CQRS patterns.

However, as ASP.NET Core has matured, many of the architectural justifications for adding MediatR as a heavy third-party dependency have faded. If you are building standard CRUD or even moderately complex enterprise APIs, it might be time to ask yourself,

Why am I routing my HTTP requests through an abstract in-memory bus when native alternatives exist?

Let’s explore why MediatR might be an unnecessary abstraction in your codebase and how you can replace its most beloved feature Pipeline Behaviors using pure .NET Dependency Injection (DI) plumbing and the Decorator pattern.

The Core Critique of MediatR

While MediatR provides an elegant mechanism for decoupling, it introduces specific friction points into a code-base,

• Obfuscated Control Flow: Because handlers are resolved dynamically, it is impossible to use standard “Go to Definition” (F12) in your IDE to trace execution directly from an endpoint to its handler. You are forced to search for the corresponding IRequestHandler type implementation.
• Debugging Overhead: Stepping through code becomes a tedious exercise of bypassing internal library code generator stacks instead of moving sequentially through your business logic.
• Unnecessary Architecture: In standard Web APIs, the mapping between an endpoint and its handler is almost always 1:1. Introducing a mediator pattern for a direct request-response cycle over complicates the system with minimal structural payback.

If you are using Minimal APIs or standard Controllers, you already have powerful endpoint routing. So why use MediatR? The answer almost always boils down to one critical feature, Pipeline Behaviors.

The “Killer Feature”: Cross-Cutting Concerns

Developers love MediatR because it makes addressing cross-cutting concerns, such as centralized logging, validation pipelines (e.g., using FluentValidation), metrics collection, and OpenTelemetry tracking incredibly clean.

Instead of cluttering every single business handler with repetitive try-catch blocks or explicit validation calls, MediatR lets you define a generic middleware pipeline around your requests:

// The classic MediatR approach
builder.Services.AddMediatR(cfg => {
    cfg.RegisterServicesFromAssembly(typeof(Program).Assembly);
    cfg.AddOpenBehavior(typeof(LoggingBehavior<,>));
    cfg.AddOpenBehavior(typeof(ValidationBehavior<,>));
});

It is a fantastic architectural model, but you do not need a third-party package to achieve it. Modern .NET allows you to implement this exact pattern natively using compile-time type-safe decorators.

The Native Alternative: DI-Based Decoration

Instead of an abstract pipeline behavior model, we can leverage the Decorator Pattern natively supported by the Microsoft.Extensions.DependencyInjection container. This allows us to transparently wrap any standard interface registration with cross-cutting behaviors.

• Defining a Domain-Driven Request Handler Interface

First, let’s establish our own lightweight, explicit handler contract. This preserves your CQRS separation without binding your domain to external packages.

public interface IRequestHandler<in TRequest, TResponse>
{
    Task<TResponse> HandleAsync(TRequest request, CancellationToken cancellationToken = default);
}

• Creating a Concrete Business Handler

Your concrete query or command handlers remain pristine. They are entirely unaware of logging, telemetry, or validation logic, adhering perfectly to the Single Responsibility Principle.

public record CreateProductCommand(string Name, decimal Price) : IRequest;

public class CreateProductHandler : IRequestHandler<CreateProductCommand, Guid>
{
    private readonly IProductRepository _repository;

    public CreateProductHandler(IProductRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> HandleAsync
      (  CreateProductCommand request, 
         CancellationToken cancellationToken = default)
    {
        var id = Guid.NewGuid();
        // Core business logic goes here...
        return id;
    }
}

• Implementing the Cross-Cutting Decorator

Now, let’s implement a generic decorator that intercepts the request execution. It implements the same interface but accepts the inner concrete handler as a dependency, wrapping it with infrastructure logic.

public class LoggingHandlerDecorator<TRequest, TResponse> : IRequestHandler<TRequest, TResponse>
{
    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly ILogger<LoggingHandlerDecorator<TRequest, TResponse>> _logger;

    public LoggingHandlerDecorator(
        IRequestHandler<TRequest, TResponse> inner, 
        ILogger<LoggingHandlerDecorator<TRequest, TResponse>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public async Task<TResponse> HandleAsync
      (TRequest request, CancellationToken cancellationToken = default)
    {
        var requestName = typeof(TRequest).Name;
        _logger.LogInformation("Executing request: {RequestName}", requestName);

        try
        {
            var response = await _inner.HandleAsync(request, cancellationToken);
            _logger.LogInformation("Successfully executed request: {RequestName}", requestName);
            return response;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Request failed: {RequestName}", requestName);
            throw;
        }
    }
} 

Wiring It Together Natively in Program.cs

To register these decorators without external help, we can write a clean extension method using the native DI container’s service factory capabilities. This gives us full architectural control over which handlers get decorated and in what order.

public static class RequestHandlerRegistrationExtensions
{
    public static IServiceCollection AddDecoratedRequestHandler<TRequest, TResponse, THandler>(
        this IServiceCollection services) 
        where THandler : class, IRequestHandler<TRequest, TResponse>
    {
        // 1. Register the concrete handler with its own concrete type
        services.AddTransient<THandler>();

        // 2. Register the interface using a factory method that constructs the decorator chain
        services.AddTransient<IRequestHandler<TRequest, TResponse>>(sp =>
        {
            var concreteHandler = sp.GetRequiredService<THandler>();
            var logger = sp.GetRequiredService<ILogger<LoggingHandlerDecorator<TRequest, TResponse>>>();

            // Wrap the core handler with our logging decorator
            return new LoggingHandlerDecorator<TRequest, TResponse>(concreteHandler, logger);
        });

        return services;
    }
}

Pro-Tip: If manual registration feels too verbose for thousands of handlers, you can use assembly scanning utilities like Scrutor to dynamically apply the .Decorate() method across your entire service collection automatically.

Your application endpoints remain perfectly clean, directly consuming the generic interface via native dependency injection:

app.MapPost("/products", async (
    CreateProductCommand command, 
    IRequestHandler<CreateProductCommand, Guid> handler) =>
{
    var result = await handler.HandleAsync(command);
    return Results.Ok(result);
});

Architectural Advantages

By shifting from an in-memory mediator library to native DI decoration, you unlock major engineering benefits:

• No Black Boxes: Your execution pathway is clear. If you place a breakpoint inside your API endpoint and step into handler.HandleAsync(), you will sequentially enter the LoggingDecorator, step through any validation layers, and land cleanly inside your actual business logic handler.
• Zero Third-Party Vendor Lock-in: Your core business logic blocks do not depend on external packages. Upgrading your framework version will never be delayed due to a breaking change in an open-source messaging mediator.
• Granular Structural Control: Unlike globally forced middleware pipelines, you can explicitly choose which command or query handlers receive specific decorators. If a high-throughput endpoint requires raw performance without validation overhead, you can register it without its decorator wrap.

Summary

MediatR has served the .NET community exceptionally well over the last decade. However, frameworks evolve. With modern ASP.NET Core DI plumbing, we can maintain clean separation of concerns, enforce CQRS principles, and leverage pipeline behaviors seamlessly using standard patterns built straight into the runtime.

Evaluate your current architecture.

Is MediatR solving a foundational problem for you, or is it merely acting as boilerplate code that your native framework can already handle?