Read time: 6 minutes ​

Jimmy Bogard, the creator of MediatR, recently announced that the library is going commercial.

Instead of panicking, I think it’s the perfect time to ask yourself if you even need it anymore.

For years, MediatR has been treated like the default architecture for “serious” ASP.NET Core apps. An essential building block for CQRS, clean separation, and testability.

But when you look at how it actually plays out in real-world codebases, the benefits are mostly theoretical.

Meanwhile, the cost in boilerplate, indirection, and time is very real.

Fortunately, there’s a better and simpler way to build APIs using Minimal APIs + Vertical Slice Architecture. And it’s gaining traction for good reason.

If you’re trying to write clear, maintainable code without overengineering, this is the approach worth learning.

More on that—and something new I’ve been working on—at the end.

Let’s dive in.

​

What is MediatR, and why do people use it?

MediatR is a popular open-source library that implements the mediator pattern:

You send a request (a Command or Query) to a mediator (ISender or IMediator), which dispatches it to a handler.

This is supposed to help you:

  • Decouple APIs from business logic
  • Improve testability
  • Enable reusable cross-cutting logic via pipeline behaviors

But here’s where it goes off the rails:

Many developers think MediatR = CQRS.

And here’s the brutal truth:

Most teams are not doing real CQRS.

They’re just splitting reads and writes into separate classes hitting the same database. That’s not CQRS. It’s unnecessary layering with no real benefit.

You don’t need MediatR to do that.

And in many cases, you don’t need CQRS at all.

Let’s see what this looks like in code.

​

The MediatR based Order endpoint

Let’s say we want to implement a POST endpoint that saves an order to PostgreSQL using EF Core.

In the MediatR world, you would implement your endpoint along these lines:

​

Then you would write the actual “logic” into a separate handler class, along with a couple of other supporting types:

​

Notice all the extra ceremony:

  • A command object
  • A result object
  • A handler class
  • A mediator registration step
  • An endpoint that does nothing but relay to the handler

All to save a row or two in a database.

Let’s see how you can do the same with no MediatR involved.

​

Using Minimal APIs + Vertical Slice Architecture

Now here’s how the exact same behavior looks as a Vertical Slice Architecture feature, here implemented as an endpoint class:

​

Then all you do is map the feature/endpoint in Program.cs like this:

​

That’s it.

  • No mediator
  • No handler
  • No extra files just to push data to a database

You see everything in one place.

You ship faster and debug faster.

You write what matters and skip what doesn’t.

​

But what about pipeline behaviors?

MediatR fans love to bring up IPipelineBehavior<TRequest, TResponse> for validation and logging.

But you don’t need a pipeline to validate a DTO:

​

Clean. Explicit. Testable.

  • No hidden behavior classes
  • No “magic” global filters
  • No stack traces you have to reverse-engineer

​

But aren’t MediatR handlers more testable?

Only if you’re testing the wrong things.

Handlers like this one don’t contain logic.

They just move data around.

That belongs in an integration test, not a unit test.

Use WebApplicationFactory and verify the full behavior through the HTTP layer.

And if you do have real logic (discount calculations, fraud detection, etc) extract that into its own class and test it there.

You don’t need a handler abstraction to write good tests.

You need boundaries that actually matter.

​

Final thoughts

MediatR was never supposed to be the default.

It’s just one tool. And in most .NET APIs today, it’s the wrong one.

Now that it’s going commercial, ask yourself:

Do I actually need this?

With Vertical Slice Architecture and minimal APIs, you get:

  • Fewer files
  • Cleaner structure
  • A dev experience that actually flows

Use the platform.

Write clear, focused endpoints as features.

And stop abstracting away the simple stuff.

​

New Azure for .NET Developers Course Drops This Tuesday

The wait is over. My new Azure for .NET Developers course launches this Tuesday, April 15 as part of the bootcamp!

If you’re already enrolled in the bootcamp, you’ve had early access for a few days now—check your dashboard and dive in.

​

For everyone else, this is your chance to:

  • Go beyond local dev and learn how to deploy your apps the right way
  • Gain real hands-on experience with Azure, specifically tailored for .NET developers
  • Build real cloud deployment skills that make you stand out

The course includes:

  • 103 lessons and 9 hours of focused, step-by-step content

  • Hands-on walkthroughs for:

    • Azure App Service
    • Microsoft Entra
    • Azure Storage
    • Azure Front Door
    • Azure Managed Identities
    • Azure PostgreSQL
    • Azure Key Vault
    • Azure Static Web Apps
  • Updated Blazor and React frontends wired up with Microsoft Entra and ready for Azure

​

You can preview the full curriculum and a short overview video here.

If you’re already in the bootcamp, enjoy the early access.

If not, stay tuned for the course launch announcement on Tuesday.

Until then!

Julio


Whenever you’re ready, there are 2 ways I can help you:

  1. .NET Cloud Developer Bootcamp: Everything you need to build production-ready .NET applications for the Azure cloud at scale.

  2. Promote your business to 20,000+ developers by sponsoring this newsletter.