No, You Really Don't Need MediatR in .NET

Hello everybody, I'm Nick and recently I made a video talking about technologies and practices I don't really use anymore in C andnet and one of those practices or packages is using the mediator package. Now many of you said yeah be gone mediator I don't want to use you anymore. However some of you said yeah but I really need mediator for certain features it offers. And I want to make this video to show you how you can actually replace all of Mediator's functionality with built-in functionality in ASP. core and really not lose anything because mediator in my opinion makes zero sense to use. And I'm not going to talk about fast endpoints here. I've talked about them in the past and they're a great replacement. But if you wanted to keep controllers or minimal APIs and still have the same handling behavior, why are you sending the request through this thing that will be handled somewhere and you can't step into it? And I know there's source generated versions of it as well. You don't need them honestly. I'm going to show you exactly how you can do it. Now here I have a very simple API. It has a bunch of product endpoints. So you have the products to sort of list them and then get them by ID, create a product, update a product and delete it. Basic CRUD API. And then you have a few other things in here. For example, the mediator handler. It's handling the query and then it's returning the response. You have another query by ID and then the response and so on. Your typical mediator setup where you have the mediator handle method. You inject any services you need in here and then you just uh return back whatever it is you want to return or whatever you created or updated, deleted and so on. Now one of the biggest arguments people that say yeah but mediator does this is that mediator has something called sort of a pipeline and behaviors you can configure. So if I go here, you will see that we add an open behavior for a login behavior and a validator or validation behavior on top of actually registering the handlers. And this is the feature everyone goes crazy over. Okay, you can do the exact same thing without mediator. Yes, it makes sense because here you can have sort of your behavior and you say that this is a crosscutting concern that logs on every request. So you're handling this request, you log it. And then when it succeeds, you say this. Or if it fails, you say this. And if you want to be a bit more um careful with this being uh finished, you might say finally here. And then you add this logging on the finally block. And then you can add metrics like it took this long to run this. Whatever it is, a flavor of this might exist in your codebase if you're using mediator. Same with the validators. So here we have some request validators and then you have the validation behavior which takes specific T request and T response and then you check for validators and then you return the errors in some way. Now this is a great feature. This is a lovely feature. It does address things like crosscutting concerns both for logging validation. It can be metrics. It can be open telemetry stuff. It can be anything you want. However,. NET has a way to solve this problem without having to resort to these tools or to these packages. And you can do this using dependency injectionbased decoration. So you don't need to have this pipeline where it goes pop and then it's like a very not clear necessarily, but if you know how mediator works, you would figure out how the flow goes. But any service, any logger, any handler, any anything can have behavior that wraps it and that can also be generic. So let me just very quickly update the project and explain step by step how this would work because it can be a bit tricky to understand if you haven't seen it before. Uh if you use the package like scrutter, I've talked about this probably 5 years ago, then you maybe know how to use the decorate method of scrutter to make this a bit easier. But you can do it purely on ASP. NET core DI plumbing extremely easily. So I applied the patch. Let's see what changed in the program. cs. You're going to see the bigger difference. So you no longer have that I mean mediator doesn't even exist. So if I go here, the package has gone. The functionality is exactly the same. Now this is done manually. You can 100% generalize it even more and you have the same query and command feature. So if you want to have your CQRS and the query and the handlers and all that, you still have it. I haven't changed the handling. You now have your own handler which you can generalize and reuse. And then you have all the handlers basically exactly as they were with some minimal changes, but fundamentally it's the same thing.

And you still have the same login and validation behavior. How does it work? Well, exactly as it was. I mean, I moved this outside of the try, but I can put it back where I put after I change it. And this looks practically identical. Same with the validator. Basically the exact same thing. Nothing changes in your code. The only change and by the way this is equally as generic as it was before. The only thing that changes is the registration. So now you have to decorate the request handlers that should have this decoration. Again you can generalize this even further. So you don't have to do it per query if you want. Uh but sometimes I like the control of where decorator is applied and what can be excluded. Um and this extension method on the services basically registers the handler and it adds it as a transient dependency and then you instantiate the decorator for the validation handler and logging. So themselves they don't change but the way they're registered in the changes because basically what happens is it says okay I'm going to handle the I don't know whichever method is in here. Wait a minute. I'm going to handle this one or because all the handlers here are in the same file. And I want to point out by the way, nothing has changed in the way the handler itself is made. So the handler still doesn't know that it has validation or logging the same way you wouldn't have it with a cross cutting concern before with the pipelines. And the only difference is that the way things are registered now in dependency injection is that first request comes in over here in the endpoints again I request handler nothing special not a specific validator or login handler. So the way registration will work is the handler itself will be added as transient. Of course you can change that to whatever lifetime you want and then you register the handler of t request t type but then you resolve the full bodied handler internally. So you have your handler and then depending on whether it should be decorated or not, you wrap it into the decorator and if you need to do it with this decorator as well or this login handler, you can do it and then every time this handle is tried to be resolved, it will be resolved decorated again. Everything here would be configurable. So you could change them if you want or you maybe you don't have to reassign them every time this way like you can change this behavior in any way you want. But this will give you the exact same cross cutting concern approach as you had before. And if you don't want to have a general decorated request handler and you want to have a decorate with logging or decorate with um I don't know um validation or anything else or if you want to use um for example you can say depending on how you build it that you need a logger decorator and you need a validation decorator. So you'd have something like this in registration. You can also totally do that. That's completely up to you. But this gives you the exact same behavior as before. Everything will function the same. You control all the flow. You can see it here. You don't have the package dependency. Obviously, pricing concern as well. But alternatives are free. You don't need them. Equally as good. You don't have to worry about any of that. The rest of the code will work exactly as it is. You don't need mediator as core supports it. But now I want to know from you. What do you think about this approach? And even if you can do it without the package, would you use the package anyway for some reason? Leave a comment down below. Let me know. Well, that's all I had for you for this video. Thank you very much for watching. And as always, keep coding.