What value does MediatR add?

[vladimir-angelov-1337]

[hmih]

[PureKrome]

@vladimir-angelov-1337 depends on your code base. Is this for a .NET 7 / .NET 8 minimal API or against a .NET Core MVC Application? Hell forbid, please don't say a Full Framework .NET 4.x MVC app...

[vladimir-angelov-1337]

.NET Core Web API (whatever version, latest works)

Curious for how the answer is different for Controllers and Minimal APIs?

[PureKrome]

Curious for how the answer is different for Controllers and Minimal APIs?

My personal take only. Can be considered pretty spicy 🔥 .

Been using MediatR for ever. ❤️ it.

Now that we have "minimal api's" from NET 7 I would contest that all the features and bonuses that MediatR offer (with respect to the mediator pattern) are now built into the framework. There's middleware (aka. MediatR behaviours) and of course with endpoint routing it's easy to create static handlers for a single endpoint. Basically -> don't need it now because it's all baked in 🧑‍🍳

As you go down with older frameworks, then yeah - it's a bit more convoluted using the out-of-the-box stuff, so MediatR helps still. Especially the old full framework framework.

[vladimir-angelov-1337]

Well middleware and endpoint routing (in the form of Minimal APIs now and previously in the form of Controllers) have existed for years. So...?

[PureKrome]

I've felt that personally all the pieces are finally in a nice place with Minimal Api's. I could also have written a website in cobol years ago, doesn't mean I would do it even though I could have. Same with MediatR - you could have done the same/similar without MediatR in FF4.x with MVC. Would have be rough but ... could have argued it could be similar (but maybe not academically be the mediator pattern). MediatR made this easy and fun. I just feel that the tooling has been inspired by this project (and others) and it's now in a mature and workable format.

spicy! 🌶️🌶️

edit: also, the endpoint routing in NET 7 I feel is really nice compared to previous versions.

[vladimir-angelov-1337]

I still don't understand if I have routing (Minimal API or Controllers) and middleware, what do I gain from the extra dispatch layer that MediatR provides? It does come at the cost of more boilerplate, because I still have to write my endpoints, but then also write the MediatR handlers. So how is that cost justified?

Is it having multiple independent handlers per query/command?

[PureKrome]

what do I gain from the extra dispatch layer

Again, this is my personal take on this. For minimal API's - you gain a negative outcome IMO 🌶️
There's 2x dispatching. 2x 'middleware'. I feel like it's not needed any more.

for Controllers, this "concept" is still everything in one single class. The ctor for a controller accepts all dependencies for all routes in this class. Where as a MediatR handler has one class per endpoint, so the dependencies and the required to satisfy this request only.

Can the Controller concept be changed? i'm sure you can re-do things to follow the "Handler" concept. but it's not an Out-of-the-box (OOTB) experience. For me -> i'm trying to use default settings and patterns and OOTB experiences as the basis for my decisions. the OOTB experience for Minimal API's does this nicely now - it's a 1-1 fit IMO.

[vladimir-angelov-1337]

You know this is available right?

public class SomethingController : ControllerBase
{
    public ActionResult GetSomething(int id, [FromServices] SomethingService somethingService)
    {
        //TODO
    }
}

You don't have to inject dependencies through the constructor.
So to me it seems even without Minimal APIs, MediatR doesn't offer anything other than hitting multiple independent handlers with 1 command/query?

[PureKrome]

yep, sure have.

like I said, I found it really helpful in the early/older days, not really now. As I keep saying, I prefer the single responsibility of a Handler, versus a controller which has multiple concerns. Like I also said, you can switch things up with controllers to also probably be a single concern also (like Handlers) but that's not the OOTB experience, which is what I'm making generalized decisions against.

[trongphan]

it force you to have request/response pattern. I think it is a huge benefit.

[vladimir-angelov-1337]

it force you to have request/response pattern. I think it is a huge benefit.

You are already forced to do that by the HTTP protocol?

[trongphan]

you can have service which have methods that accept 2,3,4 parameters ... meditor force you to have object parameter instead

[vladimir-angelov-1337]

Why is that important?

[trongphan]

a method with 5, 6 parameter is not good... readability, when add one more parameter to a method by have a object parameter is less overhead, try it you will see a lot of your unit test break when you change signature ( not break when it is object parameter)

[trongphan]

https://www.youtube.com/watch?v=gIVtrBtR-Yw

[danyo1399]

Aspnet middleware is tied to aspnet. I still prefer mediatr because

• mediatr middleware isn’t tied to aspnet core. Command handling via hangfire jobs, service bus, cli, aspnet code all go through the same middleware and follow the same pattern for command handling
• I can unit test command handlers easier without needing aspnet test server baggage

those two are the biggest reasons I can think of for sticking with mediatr. There maybe others

[danmusk]

We've been leveraging MediatR in our company for some time now. Recently, I've begun to utilize MediatR's Notifications (events) more frequently - a feature that's readily available in all our MediatR-projects, both current and "legacy", without requiring much (if any) additional effort.

I find that the consistency MediatR introduces to our projects greatly simplifies the onboarding process for new developers. With MediatR, we can direct our attention towards Request/Handlers and business logic. Regardless of the project—from FullFramework 4, .Net Core 3, .Net 8, to auxiliary tools like console apps— they all utilize MediatR Requests. This significantly reduces mental overhead when transitioning between different codebases. Just sharing my perspective.

[no1melman]

I think one of the key things to realise about this pattern is that is stems from DDD. So, if you want to know the benefit of using it, it's worth understanding what DDD brings to the table. The main difference between controllers and handlers, is that handler is SRP - one handler per "behaviour", controllers on the other hand are just a bucket to hold actions. Minimal APIs goes one step further, to say that, no need for a bucket, just tie 1 route to one handler. Yes, this is now close to MediatR, except for the fact you're now tied into minimal apis. When people moved MediatR from controllers to minimal apis, nothing happened to their behaviours, and nothing really happened in their minimal api handlers, it was just a direct port - the same can't be said for when you had to port controller actions to minimal api (you have to untangle the DI mess and any accidental coupling).

The core idea behind that is separating your Application from your Infrastructure. Allows you to model your domain without hinderance from your infrastructure. But, in order to understand why this is important - you should read up on DDD. If you believe DDD will make your development experience better, then you'll understand why MediatR will make your developer experience better.

It's not really got much to do with the technical implementation side. It's easy to go to the nth degree of saying everything is just basically the same. But, the difference here is how you model your software.

There are obviously a bunch of technical benefits once you go down the route MediatR - but everyone has already laid those out

[zachpainter77]

In my experience MediatR is great for organization of the Application layer. Each method has it's own class and validation. These classes are very modular and isolated from each other. By utilizing this structure you can ensure very loose coupling as modifying one handler will not effect another handler. In my opinion this makes the code much more scalable, maintainable, testable, and organized. It is very easy for me to teach a new developer this pattern without confusion.

This pattern also makes the controller classes much thinner since the controller now only has one dependency instead of multiple.

Service abstractions and implementations tend to become way too big and confusing to work on. By using MediatR I've seen it much easier to adhere to single responsibility principles.