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.


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 25,000+ developers by sponsoring this newsletter.