引言

首先不用查字典了辣卒，詞典查無此詞棚放。猜測是作者筆誤將Mediator寫成MediatR了照瘾。廢話少說涩拙，轉(zhuǎn)入正題。

先來簡單了解下這個開源項目MediatR（作者Jimmy Bogard耸采，也是開源項目AutoMapper的創(chuàng)建者兴泥，在此表示膜拜）：

Simple mediator implementation in .NET. In-process messaging with no dependencies. Supports request/response, commands, queries, notifications and events, synchronous and async with intelligent dispatching via C# generic variance.
.NET中的簡單中介者模式實現(xiàn)，一種進程內(nèi)消息傳遞機制（無其他外部依賴）虾宇。 支持以同步或異步的形式進行請求/響應(yīng)搓彻，命令，查詢嘱朽，通知和事件的消息傳遞旭贬，并通過C#泛型支持消息的智能調(diào)度。

如上所述燥翅，其核心是一個中介者模式的.NET實現(xiàn)骑篙，其目的是消息發(fā)送和消息處理的解耦。它支持以單播和多播形式使用同步或異步的模式來發(fā)布消息森书，創(chuàng)建和偵聽事件靶端。

中介者模式

既然是對中介者模式的一種實現(xiàn)，那么我們就有必要簡要介紹下中介者這個設(shè)計模式凛膏，以便后續(xù)展開杨名。

中介者模式類圖

中介者模式：用一個中介對象封裝一系列的對象交互，中介者使各對象不需要顯示地相互作用猖毫，從而使耦合松散台谍，而且可以獨立地改變它們之間的交互。

看上面的官方定義可能還是有點繞吁断，那么下面這張圖應(yīng)該能幫助你對中介者模式有個直觀了解趁蕊。

使用中介模式，對象之間的交互將封裝在中介對象中仔役。對象不再直接相互交互（解耦）掷伙，而是通過中介進行交互。這減少了對象之間的依賴性又兵，從而減少了耦合任柜。

那其優(yōu)缺點也在圖中很容易看出：

優(yōu)點：中介者模式的優(yōu)點就是減少類間的依賴，把原有的一對多的依賴變成了一對一的依賴沛厨，同事類只依賴中介者宙地，減少了依賴，當(dāng)然同時也降低了類間的耦合
缺點：中介者模式的缺點就是中介者會膨脹得很大逆皮，而且邏輯復(fù)雜宅粥，原本N個對象直接的相互依賴關(guān)系轉(zhuǎn)換為中介者和同事類的依賴關(guān)系，同事類越多页屠，中介者的邏輯就越復(fù)雜粹胯。

Hello MeidatR

在開始之前蓖柔，我們先來了解下其基本用法。

單播消息傳輸

單播消息傳輸风纠，也就是一對一的消息傳遞况鸣，一個消息對應(yīng)一個消息處理。其通過IRequest來抽象單播消息竹观，用IRequestHandler進行消息處理镐捧。

//構(gòu)建 消息請求
public class Ping : IRequest<string> { }
//構(gòu)建 消息處理
public class PingHandler : IRequestHandler<Ping, string> {
    public Task<string> Handle(Ping request, CancellationToken cancellationToken) {
        return Task.FromResult("Pong");
    }
}
//發(fā)送 請求
var response = await mediator.Send(new Ping());
Debug.WriteLine(response); // "Pong"

多播消息傳輸

多播消息傳輸，也就是一對多的消息傳遞臭增，一個消息對應(yīng)多個消息處理懂酱。其通過INotification來抽象多播消息，對應(yīng)的消息處理類型為INotificationHandler誊抛。

//構(gòu)建 通知消息
public class Ping : INotification { }
//構(gòu)建 消息處理器1
public class Pong1 : INotificationHandler<Ping> {
    public Task Handle(Ping notification, CancellationToken cancellationToken) {
        Debug.WriteLine("Pong 1");
        return Task.CompletedTask;
    }
}
//構(gòu)建 消息處理器2
public class Pong2 : INotificationHandler<Ping> {
    public Task Handle(Ping notification, CancellationToken cancellationToken) {
        Debug.WriteLine("Pong 2");
        return Task.CompletedTask;
    }
}

//發(fā)布消息
await mediator.Publish(new Ping());

源碼解析

對MediatR有了基本認(rèn)識后列牺，我們來看看源碼，研究下其如何實現(xiàn)的拗窃。

類圖

從代碼圖中我們可以看到其核心的對象主要包括：

1. IRequest Vs IRequestHandler
2. INotification Vs INoticifaitonHandler
3. IMediator Vs Mediator
4. Unit
5. IPipelineBehavior

IRequest Vs IRequestHandler

其中IRequest和INotification分別對應(yīng)單播和多播消息的抽象瞎领。
對于單播消息可以決定是否需要返回值選用不同的接口：

• IRequest<T> - 有返回值
• IRequest - 無返回值

這里就不得不提到其中巧妙的設(shè)計，通過引入結(jié)構(gòu)類型Unit來代表無返回的情況随夸。

/// <summary>
/// 代表無需返回值的請求
/// </summary>
public interface IRequest : IRequest<Unit> { }

/// <summary>
/// 代表有返回值的請求
/// </summary>
/// <typeparam name="TResponse">Response type</typeparam>
public interface IRequest<out TResponse> : IBaseRequest { }

/// <summary>
/// Allows for generic type constraints of objects implementing IRequest or IRequest{TResponse}
/// </summary>
public interface IBaseRequest { }

同樣對于IRequestHandler也是通過結(jié)構(gòu)類型Unit來處理不需要返回值的情況九默。

public interface IRequestHandler<in TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken);
}

public interface IRequestHandler<in TRequest> : IRequestHandler<TRequest, Unit>
    where TRequest : IRequest<Unit>
{
}

從上面我們可以看出定義了一個方法名為Handle返回值為Task的包裝類型，而因此賦予了其具有以同步和異步的方式進行消息處理的能力宾毒。我們再看一下其以異步方式進行消息處理（無返回值）的默認(rèn)實現(xiàn)AsyncRequestHandler：

public abstract class AsyncRequestHandler<TRequest> : IRequestHandler<TRequest>
    where TRequest : IRequest
{
    async Task<Unit> IRequestHandler<TRequest, Unit>.Handle(TRequest request, CancellationToken cancellationToken)
    {
        await Handle(request, cancellationToken).ConfigureAwait(false);
        return Unit.Value;
    }

    protected abstract Task Handle(TRequest request, CancellationToken cancellationToken);
}

從上面的代碼來看驼修，我們很容易看出這是裝飾模式的實現(xiàn)方式，是不是很巧妙的解決了無需返回值的場景诈铛。

最后我們來看下結(jié)構(gòu)類型Unit的定義：

public struct Unit : IEquatable<Unit>, IComparable<Unit>, IComparable
{
    public static readonly Unit Value = new Unit();

    public static readonly Task<Unit> Task = System.Threading.Tasks.Task.FromResult(Value);
    // some other code
}

IMediator Vs Mediator

MediatR 類圖

IMediator主要定義了兩個方法Send和Publish乙各，分別用于發(fā)送消息和發(fā)布通知。其默認(rèn)實現(xiàn)Mediator中定義了兩個集合幢竹，分別用來保存請求與請求處理的映射關(guān)系觅丰。

//Mediator.cs
//保存request和requesthandler的映射關(guān)系，1對1妨退。
private static readonly ConcurrentDictionary<Type, object> _requestHandlers = new ConcurrentDictionary<Type, object>();
//保存notification與notificationhandler的映射關(guān)系，
private static readonly ConcurrentDictionary<Type, NotificationHandlerWrapper> _notificationHandlers = new ConcurrentDictionary<Type, NotificationHandlerWrapper>();

這里面其又引入了兩個包裝類：RequestHandlerWrapper和NotificationHandlerWrapper蜕企。這兩個包裝類的作用就是用來傳遞ServiceFactory委托進行依賴解析咬荷。

所以說Mediator借助public delegate object ServiceFactory(Type serviceType);完成對Ioc容器的一層抽象。這樣就可以對接任意你喜歡用的Ioc容器轻掩，比如：Autofac幸乒、Windsor或ASP.NET Core默認(rèn)的Ioc容器，只需要在注冊IMediator時指定ServiceFactory類型的委托即可唇牧，比如ASP.NET Core中的做法：

ASP.NET Core注冊IMediatr

在使用ASP.NET Core提供的原生Ioc容器有些問題：Service registration crashes when registering generic handlers

IPipelineBehavior

處理管道

MeidatR支持按需配置請求管道進行消息處理罕扎。即支持在請求處理前和請求處理后添加額外行為聚唐。僅需實現(xiàn)以下兩個接口，并注冊到Ioc容器即可腔召。

• IRequestPreProcessor<in TRequest> 請求處理前接口
• IRequestPostProcessor<in TRequest, in TResponse> 請求處理后接口

其中IPipelineBehavior的默認(rèn)實現(xiàn)：RequestPreProcessorBehavior和RequestPostProcessorBehavior分別用來處理所有實現(xiàn)IRequestPreProcessor和IRequestPostProcessor接口定義的管道行為杆查。

而處理管道是如何構(gòu)建的呢？我們來看下RequestHandlerWrapperImpl的具體實現(xiàn)：

internal class RequestHandlerWrapperImpl<TRequest, TResponse> : RequestHandlerWrapper<TResponse>
    where TRequest : IRequest<TResponse>
{
    public override Task<TResponse> Handle(IRequest<TResponse> request, CancellationToken cancellationToken,
        ServiceFactory serviceFactory)
    {
        Task<TResponse> Handler() => GetHandler<IRequestHandler<TRequest, TResponse>>(serviceFactory).Handle((TRequest) request, cancellationToken);

        return serviceFactory
            .GetInstances<IPipelineBehavior<TRequest, TResponse>>()
            .Reverse()
            .Aggregate((RequestHandlerDelegate<TResponse>) Handler, (next, pipeline) => () => pipeline.Handle((TRequest)request, cancellationToken, next))();
    }
}

就這樣一個簡單的函數(shù)臀蛛，涉及的知識點還真不少亲桦，說實話我花了不少時間來理清這個邏輯。
那都涉及到哪些知識點呢浊仆？我們一個一個的來理一理客峭。

1. C# 7.0的新特性 - 局部函數(shù)
2. C# 6.0的新特性 - 表達式形式的成員函數(shù)
3. Linq高階函數(shù) - Aggregate
4. 匿名委托
5. 構(gòu)造委托函數(shù)鏈

關(guān)于第1、2個知識點抡柿，請看下面這段代碼：

public delegate int SumDelegate();//定義委托
public static void Main()
{
    //局部函數(shù)(在函數(shù)內(nèi)部定義函數(shù))
    //表達式形式的成員函數(shù)舔琅， 相當(dāng)于 int Sum() { return 1 + 2;}
    int Sum() => 1 + 2;

    var sumDelegate = (SumDelegate)Sum;//轉(zhuǎn)換為委托
    Console.WriteLine(sumDelegate());//委托調(diào)用，輸出：3
}

再看第4個知識點洲劣，匿名委托：

public delegate int SumDelegate();

SumDelegate delegater1 = delegate(){ return 1+2; }
//也相當(dāng)于
SumDelegate delegater2 => 1+2;

下面再來介紹一下Aggregate這個Linq高階函數(shù)备蚓。Aggregate是對一個集合序列進行累加操作，通過指定初始值闪檬，累加函數(shù)星著，以及結(jié)果處理函數(shù)完成計算。

函數(shù)定義：

public static TResult Aggregate<TSource,TAccumulate,TResult>
(this IEnumerable<TSource> source, 
TAccumulate seed, 
Func<TAccumulate,TSource,TAccumulate> func, 
Func<TAccumulate,TResult> resultSelector);

根據(jù)函數(shù)定義我們來寫個簡單的demo：

var nums = Enumerable.Range(2, 3);//[2,3,4]
// 計算1到5的累加之和粗悯，再將結(jié)果乘以2
var sum = nums.Aggregate(1, (total, next) => total + next, result => result * 2);// 相當(dāng)于 (((1+2)+3)+4)*2=20
Console.WriteLine(sum);//20

和函數(shù)參數(shù)進行一一對應(yīng)：

1. seed : 1
2. Func<TAccumulate,TSource,TAccumulate> func : (total, next) => total + next
3. Func<TAccumulate,TResult> resultSelector : result => result * 2

基于上面的認(rèn)識虚循，我們再來回過頭梳理一下RequestHandlerWrapperImpl。
其主要是借助委托：public delegate Task<TResponse> RequestHandlerDelegate<TResponse>();來構(gòu)造委托函數(shù)鏈來構(gòu)建處理管道样傍。

對Aggregate函數(shù)了解后横缔，我們就不難理解處理管道的構(gòu)建了。請看下圖中的代碼解讀：

請求處理管道代碼解讀

構(gòu)建流程解析

那如何保證先執(zhí)行IRequestPreProcessor再執(zhí)行IRequestPostProcessor呢衫哥？
就是在注冊到Ioc容器時必須保證順序茎刚，先注冊IRequestPreProcessor再注冊IRequestPostProcessor。（這一點很重要３贩辍Ｌ哦А！）

看到這里有沒有想到ASP.NET Core中請求管道中中間件的構(gòu)建呢蚊荣？是不是很像俄羅斯套娃初狰？先由內(nèi)而外構(gòu)建管道，再由外而內(nèi)執(zhí)行互例！

至此奢入，MediatR的實現(xiàn)思路算是理清了。

應(yīng)用場景

如文章開頭提到：MediatR是一種進程內(nèi)消息傳遞機制媳叨。 支持以同步或異步的形式進行請求/響應(yīng)腥光，命令关顷，查詢，通知和事件的消息傳遞武福，并通過C#泛型支持消息的智能調(diào)度议双。

那么我們就應(yīng)該明白，其核心是消息的解耦艘儒。因為我們幾乎都是在與消息打交道聋伦，那因此它的應(yīng)用場景就很廣泛，比如我們可以基于MediatR實現(xiàn)CQRS界睁、EventBus等觉增。

另外，還有一種應(yīng)用場景：我們知道借助依賴注入的好處是翻斟，就是解除依賴逾礁，但我們又不得不思考一個問題，隨著業(yè)務(wù)邏輯復(fù)雜度的增加访惜，構(gòu)造函數(shù)可能要注入更多的服務(wù)嘹履，當(dāng)注入的依賴太多時，其會導(dǎo)致構(gòu)造函數(shù)膨脹债热。比如：

public DashboardController(
    ICustomerRepository customerRepository,
    IOrderService orderService,
    ICustomerHistoryRepository historyRepository,
    IOrderRepository orderRepository,
    IProductRespoitory productRespoitory,
    IRelatedProductsRepository relatedProductsRepository,
    ISupportService supportService,
    ILog logger
    )  

如果借助MediatR進行改造砾嫉，也許僅需注入IMediatR就可以了。

public DashboardController(IMediatR mediatr)  

總結(jié)

看到這里窒篱，也許你應(yīng)該明白MediatR實質(zhì)上并不是嚴(yán)格意義上的中介者模式實現(xiàn)焕刮，我更傾向于其是基于Ioc容器的一層抽象，根據(jù)請求定位相應(yīng)的請求處理器進行消息處理墙杯，也就是服務(wù)定位配并。
那到這里似乎也恍然大悟MediatR這個筆誤可能是有意為之了。序員高镐，你怎么看溉旋？

參考資料：
CQRS/MediatR implementation patterns
MediatR when and why I should use it? vs 2017 webapi
ABP CQRS 實現(xiàn)案例:基于 MediatR 實現(xiàn)