What value does MediatR add?

[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.