MediatR? Not in my .NET stack

A statement I hate:

Just use MediatR.

Last week, I explained a simple tip on what I use to decrease the number of the API controller’s constructor dependencies:

Some liked the idea.

Some thought it made the code less readable.

But one comment caught my attention:

“I just need IMediator.”

The idea of sticking MediatR in every project to add another layer of abstraction is unreasonable.

Let me explain why.

One. When you call a service from a controller, adding MediatR replaces a simple method call with reflection magic. This hides flow logic. You have to:

• Find and navigate to a handler to see what happens
• Follow pipelines to find logging, validation, etc.

It makes debugging harder and can frustrate developers unfamiliar with the indirection.

Two. MediatR is now commercial. $50/month minimum for companies making over $5M/year. I hear devs saying, “I’m not a big company, I don’t have that much revenue.” Fair. But do you know what else they don’t have in that case? A complexity that justifies MediatR.

Instead of sticking it in every ToDo app, you need to consider if it’s worth the cost. If you have a clear ROI, then great. But in many cases, that’s the monthly subscription you can easily avoid.

How?

1. Use simple use case classes.
2. Keep your flow explicit and your logic easy to follow.

You will make your code readable and testable without an external library.

Or a licensing fee.