Why I DON'T use MediatR in ASP.NET Core

In this video I show my reasons for not using MediatR package. The bottom line is it gives me more maintainable code, specifically less code mass, readable control flow, faster code and one less dependency.

#csharp #mediatr #aspnetcore

[the-nasim]

I just wanted to let you know how much I admire your approach. Personally, I really appreciate how you emphasize being explicit instead of relying on magic. It's refreshing and exactly what I was looking for. I'm actually planning to incorporate a modified version of your method in my next project, because it just resonates with me. I genuinely can't thank you enough for sharing your valuable insights!

[shakeuk]

You mighy wanna be careful showing people the service locator pattern without explaining what scenarios this is Okay, it is classed as an anti pattern, though i do feel as though its fair use when building a framework, such as you are here.

Id hate to see people injecting the ServicPprovider everywhere 😂.

[TheBekker_]

Its a bit of a speed run, so will have to rewatch and try this out, but really liking this approach

[gustavogomes]

The approach you took when you talked about pipelines, look like some kind of decorator implementation using functional programming! Very nice stuff!

[adrianspikes]

Good approach with using a high order function. Better to know several ways of solving a problem.

[VitaliiShmidt-UA]

Really good point. Thanks for that. I would probably extend it like with factory probably or fluent builder to express all the pipelines flow exactly in the one place - directly in the endpoint.
By the way, there also should be some abstraction tho, 'cause You actually can miss some latter or something else and then some of pipeline or handler will not register properly.

[Nico-lwol]

9:20 What do you mean? This is basic C#. Its a list with some objects that you query using Linq. And I think people learning C# should know key information about abstract classes and interfaces. Was that a joke I didnt catch?

[mattdowns]

This works great on a small codebase or when you only need a few commands to have pipelines. For registration I have used scrutor which works quite nicely to wire things up.

In the end, the most important part of the message here is know why you are doing something and that there are options

[Sergio_Loureiro]

This complexified the program logic for a very little unsignificant performance gain. The mass code is 10 lines difference, which is also insignificant. But the complexity of the code in your approach is harder than using MediatR, So in this specific use case, you didn't convince me to drop it.

[manya.korolevskaya]

Looks good,
How'd you implement domain events handling without MeditR?

[jarnohonkanen]

Thanks! I really need to reconsider should I refactor MediatR out of my project. It's easy to use but I don't like the fact that handlers are not visible to caller and it's hard follow control flow from some caller to handler. Too much magic behind to scene IMHO.

[cocoscacao]

All good, but that reflection linq query formatting. Don't, don't, don't push it all the way to the right. I hate that format, I hate it, I hate it. xD

[WayneMunro]

the fewer dependences the better. thanks for this.

[adrian_franczak]

why this pipe instead od minimal api filters?

[roko]

Not really sure what you achieved here. I don't agree with any of the benefits you stated.

[mightybobka]

Why should we use handler classes at all if we can move their code into minimal API handlers?

[cwevers]

Aren't you rebuilding MediatR with this approach?

[lucianbumb]

I like your videos very much, but this time you lost the main goal of library like Mediatr. I prefer Mediator because is simple and straightforward.

[cubody]

Good way to understand how MediatR works. But this approach is like poison for a big project with a lot of requests. Indeed, a mediator can be used without knowing how to build your code architecturally - then it is deadly. But if you know how to use this library, then it saves a lot of effort and simplifies the code.

For example. I have 30 entities and each has a similar pipeline, I still need to bring everything to some single form. With this solution, I will have to write a unique pipeline and handler for each business process, bearing in mind that it may change someday.

Again, if I stick Generic everywhere, it will be just as confusing, or even worse.

The main point is not to use Pipeline Behaviours for everything that moves and does not move. This is a good friend and a good enemy in bad hands.

It is also worth considering that a separate pipeline for each request in a functional style is far from commonplace in C#, most people programs in an imperative style, there is no need to abuse it...

[iuribrindeiro]

I would harder use 30+ classes than using if/ELSE 🤢