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

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

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

Why build a whole toolkit when there is already a battle-tested tool? For teaching purposes? I agree! for production? Don't reinvent the wheel.

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.

HowToUseYourBrain LMAO!

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

why this pipe instead od minimal api filters?

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!

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

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

Which IDE is this one?

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

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.

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

Aren't you rebuilding MediatR with this approach?

the fewer dependences the better. thanks for this.

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

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

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

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