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!
@gustavogomes8635
Жыл бұрын
The approach you took when you talked about pipelines, look like some kind of decorator implementation using functional programming! Very nice stuff!
@RawCoding
Жыл бұрын
It’s just a function passed to another function ) which is more of a strategy. Decorator would be extending “decorating” a type
@TheBekker_
Жыл бұрын
Its a bit of a speed run, so will have to rewatch and try this out, but really liking this approach
@mattdowns358
Жыл бұрын
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
@adrianspikes6454
Жыл бұрын
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.
@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 😂.
@jarnohonkanen4321
6 ай бұрын
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.
@cocoscacao6102
Жыл бұрын
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
@weluvmusicz
Жыл бұрын
Yeah we write code LTR!
@manya.korolevskaya
Жыл бұрын
Looks good, How'd you implement domain events handling without MeditR?
@RawCoding
Жыл бұрын
a bit of a depends but mainly queues (channel) and workers.
@z0n_
Жыл бұрын
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).
@RawCoding
Жыл бұрын
@@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)))
@reasyyy-foo
Жыл бұрын
@@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
@Nico-lw5ol
3 ай бұрын
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?
@RawCoding
3 ай бұрын
yep that was sarcasm, some people are just scared of reflection
@Nico-lw5ol
3 ай бұрын
@@RawCoding Ah didnt catch that, my bad. I just couldnt believe it 😂
@Sergio_Loureiro
10 ай бұрын
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.
@bphatness3924
5 ай бұрын
Agreed. In fact, this only further convinced me to just use MediatR
@adrian_franczak
Жыл бұрын
why this pipe instead od minimal api filters?
@RawCoding
Жыл бұрын
Filter doesn’t know about model, pipe is your BL
@adrian_franczak
Жыл бұрын
@@RawCoding EndpointFilterInvocationContext has Arguments property
@WayneMunro
Жыл бұрын
the fewer dependences the better. thanks for this.
@cwevers
Жыл бұрын
Aren't you rebuilding MediatR with this approach?
@RawCoding
Жыл бұрын
no
@mightybobka
Жыл бұрын
Why should we use handler classes at all if we can move their code into minimal API handlers?
@RawCoding
Жыл бұрын
if you need a re-usable piece of logic
@swozzares
Жыл бұрын
you can test it without firing up any web server
@lucianbumb6690
Жыл бұрын
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.
@RawCoding
Жыл бұрын
0:25
@roko567
Жыл бұрын
Not really sure what you achieved here. I don't agree with any of the benefits you stated.
@RawCoding
Жыл бұрын
care to elaborate your disagreement?
@ghevisartor6005
Жыл бұрын
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
Жыл бұрын
not using mediator remove magic form code and you can click on all usages
@koderkev42
Жыл бұрын
@@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.
@NickSteffen
11 ай бұрын
@@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
@felixnotthecat4249
Жыл бұрын
Which IDE is this one?
@yunietpiloto4425
Жыл бұрын
Rider
@felixnotthecat4249
Жыл бұрын
@@yunietpiloto4425 thx
@iuribrindeiro5009
Жыл бұрын
I would harder use 30+ classes than using if/ELSE 🤢
@iuribrindeiro5009
Жыл бұрын
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.
@iuribrindeiro5009
Жыл бұрын
One tip: avoid saying “static” because “seniors” will hate it.
@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...
@waheedbhatti0
Жыл бұрын
HowToUseYourBrain LMAO!
@ddrsdiego
Жыл бұрын
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.
Пікірлер: 52