1. 程式人生 > >跟我一起學.NetCore之MediatR好像有點火

跟我一起學.NetCore之MediatR好像有點火

前言 隨著微服務的流行,而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