PRACTICAL Refactoring of MediatR Request Handlers
Вставка
- Опубліковано 7 чер 2024
- MediatR is a great library that helps us to write better software. Making sure that each action in the application has only one single request handler in our applications helps a lot in this case. But with great help also come great challenges. In most of the projects, MediatR request handler tend to become convoluted, messy and ugly. But not more! IN this video I'll show you how we can refactor MediatR request handlers in practice, by leveraging other MediatR features like pipeline bejaviors and notifications.
#dotnet #aspnetcore
Join this channel to get source code access and other perks:
/ @codewrinkles
Content
1. Intro: 00:00
2. Messy request handlers: 00:51
3. Handling logging: 02:29
4. Validation: 03:44
5. Working with DB transaction: 05:42
6. Extracting to private methods: 07:57
7. MediatR notification: 08:56
8. The result object pattern: 12:45
Also follow me here (especially if you are a self taught developer):
✅My other channel: / @danpatrascutech
✅Facebook: / danpatrascutech
✅Instagram: / danpatrascutech
✅TikTok: / danpatrascutech - Наука та технологія
I think the solution with the MediatRContext, dynamic, and Reflection can be slower than just adhering to the rule, that MediateR will always return a Result.
This was my implementation in one of my apps and will be the choice for any future ones.
Yeah, reflection is not optimal. Do you have your implementation in a GitHub repo? I'd like to take a look.
I had a question about behaviors on the Result pattern, this answered it most directly for me.
WOW WOW WOW WOW this video is super special! My best compliments Dan. Thanks for sharing
Glad you enjoyed it!
I prefer implement using Service layer and Domain events. I don´t like to use Pipeline like a application or domain solution. However, tks for your videos. I love the DDD playlist
Perfect refactoring, but how this abundance of created objects can affect the garbage collector in heavy loaded applications serving many reqests per minute?
Great video, now I have a reference for when I get questions like these :D however personally I would be very cautious about working with DbTransactions from the pipeline behaviors when dealing with distributed systems/transactions as I had some bad experiences with that in the past
What problems and what do you understand under distributed systems? Usually when you do this, you have microservices. Then each service has its self-contained transactions. You would obviously need to implement appropriate communication patterns to make sure that the database is always in a valid state, but you need to do this no matter if you use transactions in a behavior or not. I'm really curious what problems you have in mind.
@@Codewrinkles Let me correct myself a bit there, not necessary 'microservices' but indeed logically separated components, it is also related to the approach( IDesign Method) I have been adhering to which comes with it's benefits and drawbacks, and in there you have the idea of a 'Manager' which acts as an orchestrator of a sequence of actions which can be spread across different services. Those services are split logically each having their own transactions per each business operation. This comes with the price that the interaction might become "chatty" *if* left unchecked, but offers a set of other benefits like simplicity/encapsulation. Now if we inject IServiceA (which might be a repository type service) and IServiceB (which is a client to an external API for the sake of example) into a handler and then you should be cautious of how you manage your transaction in IServiceA and what if ServiceB fails however you don't want it to impact ServiceA. I never said "not using" the behaviors for transaction but be cautious about how/when to use them. The sittuation I gave is a really simple one for the sake of example, as this can get really intricate really fast and there are many approaches/patterns (retries, pubsub etc) we can use each with it's own benefit/drawback.
I think you should do a video about IDesign. I hae played around with those concepts at a certain point, but I didn't see any great value in trying to apply it in production projects.
@@Codewrinkles At some point yes :)
I would opt for instead of setting IsError = true use a IsError or Success property with lambda on the response object that returns a Errors.Count > 0 (or for success ==0). It rids the setting of the boolean IsError = true everywhere
Thanks great video!
Yep, that's a great idea and a very good way to handle it. Thanks for your comment.
Hi, it will be greate if you'll create a video about websockets.
That's something that is on my mind.
@@Codewrinkles awesome! Have a question? about previous video(IHttpClientFactory), for mobile (MAUI/Xamarin) better use one HttpFactory or named for all Interfaces?
As far as I know MAUI has the same DI infrastructure, so I would use IHttpClientFactory the same way I'd use in in Asp.Net Core. However, I don't have too much experience with these mobile technologies, so take my advice with a pinch of salt.
Maybe you want to have a look at the Nuget package OneOf for discriminated unions as replacement for your Result-class. I think you may enjoy it.