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.
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
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.
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.
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.
@@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.
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.
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.
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
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..
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.
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
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.
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.
Amazing video, really good example and very well explained
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.
Thanks for sharing your thoughts! What approach do you prefer for implementing the same feature without adding an extra abstraction layer?
@@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.
TY so much!!!
awesome
Great video. Thanks a lot. Very clear.
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.
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.
Is it possible to create and register a generic mediatr command and handler?
Hi Patrick, can we implement repository in this example?
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
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..
God created The World in 7 days. Patrick explaned CQRS in 22 minutes.
😂
True fabulous tutorial on CQRS❤❤❤❤
Thanks, you taught me how to work with the backend. Best)
You always different👍
thanks a lot 😀
You the 🐐