跟我一起學.NetCore之MediatR好像有點火
阿新 • • 發佈:2020-10-29
前言
隨著微服務的流行,而DDD(領域驅動設計)也光速般興起,CRQS(Command Query Responsibility Seperation--命令查詢職責分離)、領域事件名詞是不是經常在耳邊環繞,而MediatR元件經常用來對其技術的落地,憑這,小夥伴們說火不火?(強行引入主題,牛掰不!!!);但是今天不說微服務,也不說DDD,只說MediatR的使用,哈哈哈,開始吧;
![image-20201029084904330](https://i.loli.net/2020/10/29/VEkiqtfjHTICQeZ.png)
**正文**
![img](https://i.loli.net/2020/10/29/OVIKc4U6purmwFE.png)
二話不說就上圖,圖中大概意思就是說:MediatR是用.Net實現的簡單中介者模式,無需其他依賴就能處理程序內的訊息傳遞,支援請求/響應、命令、查詢、通知和事件的同步或非同步傳遞,通過C#的泛型智慧排程。
開源地址:https://github.com/jbogard/MediatR
Mediator有兩種訊息排程方式:
- **Request/Response**(請求/響應)訊息,只能單個處理程式處理;
一個請求/響應訊息由一個訊息處理程式進行處理;通過實現IRequest介面來抽象請求/響應訊息,實現IRequestHandler來進行訊息處理;
- **Notification**(通知)訊息,可以由多個處理程式處理;
一個通知訊息由多個訊息處理程式進行處理;通過實現INotification介面來抽象通知訊息,實現INotificationHandler來進行訊息處理;
剛才說到,MediatR元件實現了簡單的中介者模式,剛好逮住機會說說中介者設計模式;
> 中介者模式(Mediator):用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯示地相互引用,從而使其耦合鬆散,而且可以獨立地改變它們之間的互動
>
> 大話設計模式
結構如下圖(圖來源於大話設計模式):
![img](https://i.loli.net/2020/10/29/4wtFbOPlqfUDW8g.png)
上面是不是有點專業,咱們找個生活中例子,比如房產中介,先假如沒有房產中介這個中間物件時,賣房者和買房者之間都是互相關聯,耦合在一起,賣房者之間可以互相推薦找優質房源給買房者,買房者之間也能互相分享好的房源,自己不適合,朋友或者親戚可能適合,如下圖:
![img](https://i.loli.net/2020/10/29/ZRdbmHE53N4skla.png)
上圖看上去是不是顯得每個人都很忙,而且需要對接不同的人,電話和資訊肯定少不了,那是不是就沒時間幹其他的了,比如上班、陪孩、約會這些咋可能少嘛,對不對;有了房屋中介之後,看下圖:
![img](https://i.loli.net/2020/10/29/JORPXzVKSbAnFwd.png)
這樣看著是不是比較清晰了,賣房找中介,買房找中介,通過中介統一分享資訊,這樣就忙房屋中介即可(人家專業,就是幹這行的),其餘每個人,就和中介互動資訊即可。
結合上面的結構圖和案例,程式碼如下:
由於有多個房屋中介公司,這裡先將其進行抽象出來,相當於結構圖中Mediator:
![img](https://i.loli.net/2020/10/29/NH2xkTdnCfOKZpB.png)
然後將賣房者和買房者進行抽象化,相當於結構圖中的Colleague,如下:
![img](https://i.loli.net/2020/10/29/UqxhMt9nID6kLQo.png)
實現具體的賣房者和買房者,相當於結構圖中的ConcreteColleague1、ConcreteColleague2,如下:
![img](https://i.loli.net/2020/10/29/FVeU5nBMD179kGA.png)
實現具體的中介者,相當於結構圖中的ConcreteMediator,如下圖:
![img](https://i.loli.net/2020/10/29/6BcWApvVC3iUdkm.png)
使用及執行效果如下:
![img](https://i.loli.net/2020/10/29/AS7eYFhj5sz2WLP.png)
由上可以明顯感覺到中介者好處,各物件沒有直接耦合,而是通過中介者進行各物件的連線,從原來的網狀結構就變得相對單一;但具體的中介者的任務會因為ConcreteColleague的越來越多變得比較繁重,程式碼不容易維護,因為中介者需要了解所有ConcreteColleague物件操作; 以上買賣房的思想可能沒有很好的體現各個ConcreteColleague互動,但如果換成房屋出租,感覺是不是稍微直接一點啦。
Mediator中介者模式就簡單到這吧,回到文章主題MediatR元件,停!!!小夥伴會問:Mediator中介者和MediatR元件是不是哪個詞寫錯了?如果指的是單詞的話,MediatR不對,但從功能角度上看,MediatR不僅僅實現了Mediator中介者模式,而且加入了依賴注入,使得使用更加方便,這可能就是作者將其命名MediatR的原因吧。後續抽時間再和小夥伴們一起扒扒原始碼,這裡就先看看怎麼使用,看看到底有多方便,先用控制檯程式演示↓↓↓
**請求/響應訊息及其處理:**
![img](https://i.loli.net/2020/10/29/Lixor8PfzKaZXFg.png)
使用及執行如下圖:
![img](https://i.loli.net/2020/10/29/ThrjcSPbRxVnHI7.png)
以上定義簡單分為以下幾步:
1. 請求訊息和請求訊息處理類;
2. 註冊相關MediatR相關元件;
3. 從容器中獲取到中介者,通過中介者傳送訊息;
以上簡單三步完成之後,對應訊息型別的處理類就會自動處理,這就是據泛型智慧處理對應訊息功能。這些都是MediatR元件內部處理好,為小夥伴們減少建立物件、關聯中介者、訊息關聯等操作。
請求/響應訊息是一對一處理的,假如有多個處理怎麼辦呢?
![img](https://i.loli.net/2020/10/29/c78wEOgM5Yt2CmJ.png)
**結論:當同一個型別請求/響應訊息有多個處理類時,會根據掃描註冊時進行****覆蓋,最終只有一個處理類生效。**
應用場景:通常會用來實現CQRS(命令查詢職責分離),也可以用於模組解耦相關場景。
注意:
- IRequest代表無返回值;
- IRequest