Thanks for the Video and the super explanation ❤ It might feel super clean in the first place. However, for me the mediator added another layer of abstraction which made it harder to analyze dependencies. Moreover, I wondered how to execute multiple commands in a transaction.
@Guillen860625 күн бұрын
Great explanation.Plain and simple. I like the fact the Batman has a higher level than Ironman
@ChathurangaLiyanagenk2 ай бұрын
Short and sweet. Thanks a lot.❤
@TrinitaRebeccaLasradoАй бұрын
You made it so easy to understand, Thank you❤
@-INC0GNIT0-7 ай бұрын
Great stuff, I always like your channel because you always show stuff we developers really need and the common streamers always seem to ignore to show like: authorization, mailing, refreshing tokens, ... it's always very knowledgeable engineering concepts
@eyoo3696 ай бұрын
Everyone saying that Mediatr is useless. For our team the biggest advantage is having controllers with literally 1 line of code and a single dependancy injection which is MediatR itself. Also having your project structured by Features (commands & queries) makes it so much more easy to navigate as opposed to a God-like 1000+ line service class. And the best of all is that testing commands & queries is a lot easier than testing and mocking a service class. Everyone can work on a feature and saves us git merge headaches when 2 or more devs are working in the same Service class.
@shadmansudipto72872 ай бұрын
You could do the same without mediatr right? although I guess this enforced the pattern so your coworkers don't go back to putting everything in one file.
@eyoo3692 ай бұрын
@@shadmansudipto7287 Absolutely, could've been done without MediatR but having mediatr helps by achieving clean pipeline middleware. It works seamlessly together with FluentValidation and other libraries .
@portahack5 ай бұрын
Amazing video, really good example and very well explained
@daWoody017 ай бұрын
Any benefits or issues using MediatR in a Blazor component? I usually inject a service into a Blazor component and use the service to make any queries or commands.
@imadabab6 ай бұрын
Great video. Thanks a lot. Very clear.
@oseifrimpongggАй бұрын
Simple. Thanks!
@codefoxtrot7 ай бұрын
It was wayyyy simpler before MediatR and CRQS, but thanks for explaining in a quick demo! Though it leaves me wondering what's the benefit of doing this in a larger project? Seems like it just adds another layer of work.
@SireTheKing5 ай бұрын
CQRS is a pattern that allows developers to decouple everything, which makes it easier to update and feature add-ons via interfaces. it also allows for easier testing since you can mock the dependencies. This creates loosely coupled applications, and the trade-off is more complexity.
@dimasvyrydiuk59555 ай бұрын
Thanks, you taught me how to work with the backend. Best)
@axelbryancasauran51593 ай бұрын
Is it possible to create and register a generic mediatr command and handler?
@adam-xt8te7 ай бұрын
God created The World in 7 days. Patrick explaned CQRS in 22 minutes.
@PatrickGod7 ай бұрын
😂
@harishchaudhari96815 ай бұрын
True fabulous tutorial on CQRS❤❤❤❤
@dasfahrer81877 ай бұрын
Interesting, but it's just another abstraction layer that doesn't buy you much. If you're managing multiple brownfield projects that already have a standard pattern, introducing this only adds time and confusion to technical debt as you're now having to navigate multiple ways of doing things.
@PatrickGod7 ай бұрын
Thanks for sharing your thoughts! What approach do you prefer for implementing the same feature without adding an extra abstraction layer?
@dasfahrer81877 ай бұрын
@@PatrickGod Well, for some context, we have dozens of projects with API interfaces in them that hit various services across our own internal network as well as external endpoints. That in and of itself is a lot to manage so we try to keep things as generic as possible w/o having to rely on too many third party NuGet packages that don't bring much to the table for us. Because of that, we rolled our own base service implementations and interfaces to fit our security and network requirements. They don't follow a specific design or organizational patterns other than separating concerns and decoupling key areas where we know potentially breaking changes have taken place in the past or are likely to take place. We do regularly re-evaluate our architecture and implementations to see if there are any new ideas/tech that may help us manage things more efficiently, but so far we have yet to find anything significant enough to warrant a complete redesign and rebuild. Typically what we'll do is change something like a series of classes over to records and make the corresponding downstream changes to properly utilize them.
@samehgenah80677 ай бұрын
You always different👍
@sergiodaniel66563 ай бұрын
TY so much!!!
@quanghungnguyen30187 ай бұрын
thanks a lot 😀
@50LEDBURY2 ай бұрын
where is the download link?
@n.sharma58105 ай бұрын
Hi Patrick, can we implement repository in this example?
@martinzaloga38433 ай бұрын
I think that here the repo is represented by the DBContext class, which is injected to the command and query handlers, which are replacing the service. Is it more clear now? :-D
@baebcbcaeАй бұрын
try more complicated examples please, creating entity A requires automatic creation of entity B, it should be different commands but it must be atomic and it might be concurrent and result must be unique by field but you can't use unique index on DB... how you organise your handlers then ?
@nobuffer-indef3 ай бұрын
awesome
@TheLUCKYONETutorials7 ай бұрын
I get the idea. But it seems just like another layer of work and complexity. I dont think that I want to implement this every time I start a new project..