MediatR: Why should you use it?

Подписаться 85 тыс.

Просмотров 55 тыс.

50% 1

MediatR is a library that has gotten more and more popular over the years. I'll cover the 3 reasons why I think it's useful and well as 1 reason why you might want to look at something else.
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to source code & demos!
/ @codeopinion
🔥 Don't have the JOIN button? Support me on Patreon!
/ codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
#mediatr #softwarearchitecture #dotnet

Наука

Опубликовано:

15 сен 2020

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 53

@sultonbekrakhimov6623 3 месяца назад

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!

@marna_li 2 года назад

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.

@vktop2 8 месяцев назад

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

@mishamovdivar 3 года назад

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 3 года назад

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 3 года назад

@@CodeOpinion please do :)

@georgepinargote 9 месяцев назад

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

@sampsonorson 3 года назад

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

@CodeOpinion 3 года назад

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

@johnf7755 3 года назад

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 3 года назад

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?

@Imonfire328 2 года назад

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?

@iliyan-kulishev 2 года назад

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 2 года назад

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

@rainron2664 3 года назад

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 3 года назад

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

@mana20 2 года назад

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 2 года назад

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

@jameshickey84 3 года назад

Good stuff 👍

@kapquidlat1122 2 года назад

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 2 года назад

One of the major benefits are if you want to create a request pipeline. Check out the video I did on Pipes & Filters: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-msXtN15qXOE.html

@kapquidlat1122 2 года назад

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

@iamnoob7593 Год назад

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

@SlashTagged 2 года назад

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 2 года назад

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.

@GR_PROF 3 года назад

What font is used in the editor ?

@CodeOpinion 3 года назад

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

@GR_PROF 3 года назад

@@CodeOpinion Thanks

@puravupadhyay2961 6 месяцев назад

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

@codewithkashif 2 года назад

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

@CodeOpinion 2 года назад

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 2 года назад

@@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!

@DanielRodriguez-ds2qs Год назад

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

@CodeOpinion Год назад

Ha! Thanks 👍

@brandonpearman9218 3 года назад

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 3 года назад

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 3 года назад

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 3 года назад

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.

@dimapetrichenko6190 4 месяца назад

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

@adnanahmed316 3 года назад

REPO LINK????

@CodeOpinion 3 года назад

github.com/jbogard/MediatR

@adnanahmed316 3 года назад

@@CodeOpinion love you

@rmbl349 2 года назад

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

@CodeOpinion 2 года назад

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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-msXtN15qXOE.html