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!
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
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 😂.
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.
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?
Wouldn't it be difficult to handle the events inside the same transaction if channels or workers were used? The only reason I would pick MediatR today would be to have the synchronous messaging functionality (notifications).
@@z0n_ you're not going to have a transaction if the domain events are distributed (mediatr doesn't help here). If you need them within a transaction then it can't be channels and workers, you'll have: await Task.WhenAll(handlers.Select(x => x.Handle(event)))
@@RawCoding it would be interesting if you would explore the subject more and maybe continue with an events dispatching implementation video?:)) i would definitely watch
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.
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
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.
He achieved explaining that you can have the same if not better result with ur custom code instead of a package that many treat as a must have. It's not something like remplementing imagesharp.
@@adrian_franczak "Magic"? LoL. Guy talks down on a Mediatr while simultaneously managing database code with EF "Code Migrations" (05:22). What has the developer community become.
@@koderkev42 Yea, of all the “magic” libraries out Mediatr is very straight forward and easy to understand and follow… like it’s really just a bit of boilerplate reduction. Its much easier to follow it than EF Core and automapper. I would much rather use it than make this manually
For real now, I would love to see some functional approach example. I’ve been implementing some RoP + kind of the mediator pattern as well and I just don’t see the need to use mediatr yet.
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...
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!
The approach you took when you talked about pipelines, look like some kind of decorator implementation using functional programming! Very nice stuff!
It’s just a function passed to another function ) which is more of a strategy. Decorator would be extending “decorating” a type
Its a bit of a speed run, so will have to rewatch and try this out, but really liking this approach
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
Good approach with using a high order function. Better to know several ways of solving a problem.
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 😂.
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.
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?
yep that was sarcasm, some people are just scared of reflection
@@RawCoding Ah didnt catch that, my bad. I just couldnt believe it 😂
Looks good,
How'd you implement domain events handling without MeditR?
a bit of a depends but mainly queues (channel) and workers.
Wouldn't it be difficult to handle the events inside the same transaction if channels or workers were used? The only reason I would pick MediatR today would be to have the synchronous messaging functionality (notifications).
@@z0n_ you're not going to have a transaction if the domain events are distributed (mediatr doesn't help here). If you need them within a transaction then it can't be channels and workers, you'll have: await Task.WhenAll(handlers.Select(x => x.Handle(event)))
@@RawCoding it would be interesting if you would explore the subject more and maybe continue with an events dispatching implementation video?:)) i would definitely watch
why this pipe instead od minimal api filters?
Filter doesn’t know about model, pipe is your BL
@@RawCoding EndpointFilterInvocationContext has Arguments property
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.
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
Yeah we write code LTR!
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.
Agreed. In fact, this only further convinced me to just use MediatR
the fewer dependences the better. thanks for this.
Why should we use handler classes at all if we can move their code into minimal API handlers?
if you need a re-usable piece of logic
you can test it without firing up any web server
Aren't you rebuilding MediatR with this approach?
no
Which IDE is this one?
Rider
@@yunietpiloto4425 thx
Not really sure what you achieved here. I don't agree with any of the benefits you stated.
care to elaborate your disagreement?
He achieved explaining that you can have the same if not better result with ur custom code instead of a package that many treat as a must have.
It's not something like remplementing imagesharp.
not using mediator remove magic form code and you can click on all usages
@@adrian_franczak "Magic"? LoL. Guy talks down on a Mediatr while simultaneously managing database code with EF "Code Migrations" (05:22). What has the developer community become.
@@koderkev42 Yea, of all the “magic” libraries out Mediatr is very straight forward and easy to understand and follow… like it’s really just a bit of boilerplate reduction. Its much easier to follow it than EF Core and automapper. I would much rather use it than make this manually
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.
0:25
I would harder use 30+ classes than using if/ELSE 🤢
For real now, I would love to see some functional approach example. I’ve been implementing some RoP + kind of the mediator pattern as well and I just don’t see the need to use mediatr yet.
One tip: avoid saying “static” because “seniors” will hate it.
This is highly suspicious and not good practice.
Source: feeling
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.
Toolkit? It’s a higher order function
HowToUseYourBrain LMAO!