MediatR: Why should you use it?

[@sulton-max]

When this video came out I just started learning APIs. And started using MediatR in my APIs last year The reasons I use it - clean architecture - I like to divide each request to query, command, events - transactions - although not many projects are focusing on handling these, MediatR is the best place for it I think - in-memory event bus - to ship dev apps fast, it's just the perfect solution I think, I use `IEventBusBroker` initially implemented only with `MediatR`, then can use whatever event bus I want

[@david3552]

I am a neophyte to clean architecture and your chanel is a fantastic way to get a clear overview of complicated subjects. Thanks!

[@CodeOpinion]

Thanks!

[@mishamovdivar]

Thanks for sharing. One more reason i would add for using mediatr is that, you not only want to separate out the business logic from controller because that might be used by another client (webjob, etc) but to respect the Single Responsibility and Separation of Concerns which will bring, at least, code readability and testability benefits

[@CodeOpinion]

Yes for sure, great point. If you use behaviors/middleware/pipeline, it makes separation and therefor testing nice. I should create a video on exactly that. Thanks for the comment!

[@MaxLaurieHutchinson]

@@CodeOpinion please do :)

[@marna_li]

I remember starting using MediatR 3-4 years ago. I just used the Requests and did not get what it was all about. I did not understand loosely-coupled monoliths, microservices, messaging or event-driven architecture. In hindsight these would be useful back then. I did not even know about this channel until last year, Now I feel like I have excelled a lot in just that short time.

[@Imonfire328]

I’ve been using mediatr almost exclusively for a year and the biggest feature for me is the middleware layer where I can assign user specific information I don’t want exposed in the view. Also each handler has a defined “contract” in the command request in what’s being changed or allowed to be modified on that request. Really easy to read, and makes the code difficult to screw up imo

[@iamnoob7593]

what do u mean not exposed in view ? its just backend code right?

[@johnf7755]

I feel I achieve the decoupling you talk about here through, you know, interfaces, dependency injection, hexagonal architecture etc and the "pipeline" through generic handler functions if required. Language features and some good architecture. The code documents it's dependencies. I don't see that with MediatR. Is one of your arguments for it really that you need MediatR because you might want to call your business logic outside of a web context? It feels very cargo cult to me.

[@CodeOpinion]

With anything that becomes popular, I think it's usage could become cargo cult. People just using it without any idea why. Hence why I'm trying to describe some reasons why I find the pattern useful. That doesn't mean those reasons apply to the context of the project anyone else working on. Converting HTTP requests to application requests is a big reason in the applications I generally live in. As you asked, yes, it's never just a web context for me. There are generally many different inputs to applications that I work in besides HTTP. It also becomes a gateway for a few more things such as using the same paradigm for in-process and out-of-process messaging handling. It also servers as a gateway for for vertical slice feature based style of writing and organizing code. I'll be getting more to these ideas in future videos for sure. I appreciate the comment.

[@impeRAtoR28161621]

But what is difference to simple having business layer and API that references that business layer and thats it?

[@vktop2]

Good video, can I use the Mediator pattern to decouple what I used to decouple with Interfaces? Regards

[@iliyan-kulishev]

In my assessment of MediatR, I wouldn't bother using it if I didn't have a need for some kind of filtering. Otherwise I see nothing wrong of just referring to my handlers directly.

[@CodeOpinion]

Agree, if you're not creating a pipeline for a request a lot of the benefit is lost.

[@leepaulalexander]

I haven't looked at mediatR but in your example throwing an exception to convey a not found doesn't sit well with me...for these reasons: performance, code clarity and finally separation of concerns.

[@georgepinargote]

Hi sir, How to use it like a vertical slice Gateway?

[@sampsonorson]

Nice tutorial. I remember you also talked about MediatR sometime ago.

[@CodeOpinion]

Yes I have in the past, I think mainly on codeopinion.com

[@codewithkashif]

I have a quick question i.e. why people use MediatR with CQRS only?

[@CodeOpinion]

Not sure. It doesn't imply or force you to use CQRS. You could have a request that changes state and also returns state. Hence why it's called an IRequest and not an ICommand/IQuery.

[@codewithkashif]

@@CodeOpinion yeah totally agreed with you and i was also on same notion. I just have seen over internet people mostly uses MediatR with CQRS only, that’s why i was little cautious. Thanks for your quick help!

[@kapquidlat1122]

Thanks for this very informative content. I can see some benefits to using MediatR but isn't this over-engineering? For MVC apps can't we just stick to DI, services and repositories for decoupling and separation of concerns? Or am I missing the point? Hope you can shed some light on this.

[@CodeOpinion]

One of the major benefits are if you want to create a request pipeline. Check out the video I did on Pipes & Filters: kzbin.info/www/bejne/o6S7pYFnataLhac

[@kapquidlat1122]

@@CodeOpinion Thanks! I'm going to watch that next.

[@iamnoob7593]

@@CodeOpinion Thanks i wanted to know what is this request pipeline for

[@SlashTagged]

In regards to using a messaging consumer as an entry point, how would you handle the application logic? On one hand, you could put that logic in the "Application" project and have the Consumer project reference it, but then you introduce (informational) coupling b/c the consumer may only care about one function/handler from that dependency. On the other hand, you could put the logic in the Consumer project (only), but then you'll need you'll need to fiddle around in that project any time the business logic changes. Does it even make sense to extract out functionality like this to some shared project that both a messaging consumer AND web application (REST API) can use? Keep up the great work! These videos have been very helpful.

[@CodeOpinion]

I don't separate them. I often think about message handlers being invoked from anywhere. So as mentioned it could be invoked from a web request or possibly from consuming a message. *_Often_* times the context of how it's being invoked doesn't matter. In some situations it does but in the vast majority (in my cases) it doesn't.

[@DanielRodriguez-ds2qs]

Just leaving a message here to show appreciation and for the youtube algorithm

[@CodeOpinion]

Ha! Thanks 👍

[@mana20]

Do you have a preference for Messaging and Message Broker Frameworks? I'm sure it depends on the project, but do you typically lean towards any specific ones?

[@CodeOpinion]

If you're in the .NET space, NServiceBus, MassTransit, Brighter.

[@brandonpearman9218]

point 1 & 2: mediatr not needed at all to do these point 3 is an ok reason if you like that pipeline style, but not needed. After working with mediatr for 3 years now its quite annoying, Especially because it makes coding harder especially for junior or devs unfamiliar with mediatr. So here are some counters reasons 1. cant easily go to the implementation, like you could with a method (f12). 2. pipeline implementations often go unnoticed cause they are harder to find 3. lack of an interface dependency in the controller makes the flow more illusive 4. unneeded nuget package dependencies 5. isolation of handlers can be a good thing but can also create a lot of complexity when its a bad thing 6. usually get an explosion of classes because you need to keep adding a butt load of handlers (which was once a single class)

[@CodeOpinion]

I can get behind these arguments. I don't necessarily disagree with any of them! I would say my biggest argument for using it is to get a taste of messaging. At around 4:50 is really what it boils down to. A lot of messaging libraries in the .NET space use a type routing, which is how MediatR works, so you'll still run into the same issues you described in your list if you use almost any of them.

[@brandonpearman9218]

Thanks for reply. Yeah agreed those down sides are acceptable when dealing with a queue but i see many projects which use mediatr and nservice bus so some handlers are from a queue and others are just there to be annoying. The reason they say is that mediatr = CQRS, as if it is not possible to do CQRS without it. Also i hear the reason, to enforce SRP, which they define one public method per class.

[@vinipaivas]

Completely agree with you guys. It seems like MediatR might be more useful for applications that are not web applications. Web apps have a pretty concise flow of code already while background process can have all sort of entry points which, depending on the dev, can get quite messy. I believe MediatR brings some standards and enforce better code separation in those scenarios.

[@rainron2664]

Sir how did you configure that kind of fixed intellisense thing on the side of yout code? ive been seeing that from some tutorial vids. Im curious, and find it helpful. Thank you and more power 😊

[@CodeOpinion]

The type definition? It's built into Rider. Really useful.

[@puravupadhyay2961]

I figured out that you're a Canadian by the way you said "About" 😀

[@GR_PROF]

What font is used in the editor ?

[@CodeOpinion]

Just the default font in Rider which I believe is called "JetBrains Mono"

[@GR_PROF]

@@CodeOpinion Thanks

[@jameshickey84]

Good stuff 👍

[@dimapetrichenko6190]

Nothing explained properly, how to connect that abstract behaviour to you concrete mediator

[@adnanahmed316]

REPO LINK????

[@CodeOpinion]

github.com/jbogard/MediatR

[@adnanahmed316]

@@CodeOpinion love you

[@yasser2768]

Holy Moly I will stick to Unit Of Work and Repositories

[@rmbl349]

I don't see why anybody should use this. I tried multiple times over 3 teams and it was just more complicated.

[@CodeOpinion]

If you're not using what Mediator calls behaviors to create a request pipeline, I'd agree in a lot of situations that it's not necessary. I've created a video about Pipes & Filters kzbin.info/www/bejne/o6S7pYFnataLhac

[@megasuperlexa2]

It is as unneeded as losing 30% of screen real estate on a fancy mic which sound exactly like builtin MacBook one (speechwise)

[@CodeOpinion]

Thanks for your wonderful feedback 😆