在Avalonia項目中使用MediatR和MS.DI庫實現事件驅動通信

大家好，我是沙漠盡頭的狼！

AvaloniaUI是一個強大的跨平臺.NET客戶端開發框架，讓開發者能夠針對Windows、Linux、macOS、Android和iOS等多個平臺構建應用程式。在構建複雜的應用程式時，模塊化和組件間的通信變得尤為重要。Prism框架提供了模塊化的開發方式，支持插件的熱拔插，而MediatR則是一個實現了中介者（Mediator）模式的事件訂閱發佈框架，非常適合用於模塊之間以及模塊與主程式之間的通信。

本文重點是介紹MediatR，它 是 .NET 中的開源簡單中介者模式實現。它通過一種進程內消息傳遞機制（無其他外部依賴），進行請求/響應、命令、查詢、通知和事件的消息傳遞，並通過泛型來支持消息的智能調度。開源庫地址是 https://github.com/jbogard/MediatR。

本文將詳細介紹如何在Avalonia項目中使用MediatR和Microsoft的依賴註入（MS.DI）庫來實現事件驅動的通信。

0. 基礎知識準備-MediatR的基本用法

MediatR中有兩種消息傳遞的方式：

• Request/Response，用於一個單獨的Handler。
• Notification，用於多個Handler。

Request/Response

Request/Response 有點類似於 HTTP 的 Request/Response，發出一個 Request 會得到一個 Response。

Request 消息在 MediatR 中，有兩種類型：

• IRequest<T> 返回一個T類型的值。
• IRequest 不返回值。

對於每個 request 類型，都有相應的 handler 介面：

• IRequestHandler<T, U> 實現該介面並返回 Task<U>
• RequestHandler<T, U> 繼承該類並返回 U
• IRequestHandler<T> 實現該介面並返回 Task<Unit>
• AsyncRequestHandler<T> 繼承該類並返回 Task
• RequestHandler<T> 繼承該類不返回

Notification

Notification 就是通知，調用者發出一次，然後可以有多個處理者參與處理。

1. 準備工作

首先，確保你的Avalonia項目中已經安裝了必要的NuGet包。你將需要Prism.DryIoc.Avalonia作為依賴註入容器，以及MediatR來處理事件的發佈和訂閱。此外，為了將MediatR集成到DryIoc容器中，你還需要DryIoc.Microsoft.DependencyInjection包（這裡感謝網友寒提供的技術解答）。

在項目的.csproj文件或NuGet包管理器中添加以下引用：

<PackageReference Include="Prism.DryIoc.Avalonia" Version="8.1.97.11072" /> 
<PackageReference Include="MediatR" Version="12.2.0" />  
<PackageReference Include="DryIoc.Microsoft.DependencyInjection" Version="8.0.0-preview-01" />

2. 配置容器和註冊服務

在Avalonia項目中，你需要配置DryIoc容器以使用Microsoft的DI擴展，並註冊MediatR服務。這通常在你的主啟動類（如App.axaml.cs）中完成。

以下是配置容器和註冊服務的示例代碼：

namespace CodeWF.Tools.Desktop;

public class App : PrismApplication
{
    // 省略了模塊註入等和主題無關的代碼，有興趣源碼在文末可查

    /// <summary>
    /// 1、DryIoc.Microsoft.DependencyInjection低版本可不要這個方法（5.1.0及以下）
    /// 2、高版本必須，否則會拋出異常：System.MissingMethodException:“Method not found: 'DryIoc.Rules DryIoc.Rules.WithoutFastExpressionCompiler()'.”
    /// 參考issues：https://github.com/dadhi/DryIoc/issues/529
    /// </summary>
    /// <returns></returns>
    protected override Rules CreateContainerRules()
    {
        return Rules.Default.WithConcreteTypeDynamicRegistrations(reuse: Reuse.Transient)
            .With(Made.Of(FactoryMethod.ConstructorWithResolvableArguments))
            .WithFuncAndLazyWithoutRegistration()
            .WithTrackingDisposableTransients()
            //.WithoutFastExpressionCompiler()
            .WithFactorySelector(Rules.SelectLastRegisteredFactory());
    }

    protected override IContainerExtension CreateContainerExtension()
    {
        IContainer container = new Container(CreateContainerRules());
        container.WithDependencyInjectionAdapter();

        return new DryIocContainerExtension(container);
    }

    protected override void RegisterRequiredTypes(IContainerRegistry containerRegistry)
    {
        base.RegisterRequiredTypes(containerRegistry);

        IServiceCollection services = ConfigureServices();

        IContainer container = ((IContainerExtension<IContainer>)containerRegistry).Instance;

        container.Populate(services);
    }

    private static ServiceCollection ConfigureServices()
    {
        var services = new ServiceCollection();

        // 註入MediatR
        var assemblies = AppDomain.CurrentDomain.GetAssemblies().ToList();

        // 添加模塊註入，未顯示調用模塊類型前，模塊程式集是未載入到當前程式域`AppDomain.CurrentDomain`的
        var assembly = typeof(SlugifyStringModule).GetAssembly();
        assemblies.Add(assembly);
        services.AddMediatR(configure =>
        {
            configure.RegisterServicesFromAssemblies(assemblies.ToArray());
        });

        return services;
    }
}

在上面的代碼中，我們重寫了CreateContainerRules、CreateContainerExtension和RegisterRequiredTypes方法以配置DryIoc容器，並註冊了MediatR服務和相關處理程式。

註意，在註冊MediatR服務時，我們從當前已載入的程式集列表中查找並註冊處理程式。如果模塊是按需載入的，請確保在註冊處理程式之前已載入了相應的模塊。

此外，我們還演示瞭如何手動添加模塊程式集到列表中以便註冊處理程式。這通常在你需要顯式控制哪些模塊和處理程式被註冊時很有用。但是，請註意，在大多數情況下，你可能希望使用更自動化的方式來載入和註冊模塊及處理程式（例如，通過掃描特定目錄或使用約定等）。這取決於你的具體需求和項目結構。

另外，請註意代碼中的註釋和說明，它們提供了有關每個步驟和配置的額外信息。在實際項目中，你可能需要根據項目的實際情況和需求進行相應的調整和優化。例如，你可能需要處理迴圈依賴、配置作用域、使用攔截器或裝飾器等高級功能。這些都可以在DryIoc和MediatR的文檔中找到更詳細的說明和示例。

3. MediatR2種傳遞方式

有了前面的基礎知識準備，我們添加類庫工程CodeWF.Tools.MediatR.Notifications，並添加請求定義（主工程及模塊的響應處理程式需要實現）：

public class TestRequest : IRequest<string>
{
    public string? Args { get; set; }
}

添加通知定義：

public class TestNotification : INotification
{
    public string? Args { get; set; }
}

請求和通知定義結構一樣（實現介面不同），只有一個字元串屬性。

4. 添加處理程式

示例工程結構如下，因為該開源項目（文末鏈接）寫在站長的AvaloniaUI桌面工具工程，本文只關註如下圖3個工程即可：

在AvaloniaUI主工程(CodeWF.Tools.Desktop)添加請求響應處理程式：

public class TestHandler : IRequestHandler<TestRequest, string>
{
    public async Task<string> Handle(TestRequest request, CancellationToken cancellationToken)
    {
        return await Task.FromResult($"主工程處理程式：Args = {request.Args}, Now = {DateTime.Now}");
    }
}

添加通知響應處理程式：

public class TestNotificationHandler(INotificationService notificationService) : INotificationHandler<TestNotification>
{
    public Task Handle(TestNotification notification, CancellationToken cancellationToken)
    {
        notificationService.Show("Notification",
            $"主工程Notification處理程式：Args = {notification.Args}, Now = {DateTime.Now}");
        return Task.CompletedTask;
    }
}

在模塊【CodeWF.Tools.Modules.SlugifyString】中添加請求響應處理程式(因為順序關係，不會觸發，這裡添加只是演示請求為一對一響應）：

public class TestHandler : IRequestHandler<TestRequest, string>
{
    public async Task<string> Handle(TestRequest request, CancellationToken cancellationToken)
    {
        return await Task.FromResult($"模塊【SlugifyString】Request處理程式：Args = {request.Args}, Now = {DateTime.Now}");
    }
}

添加通知響應處理程式（會和主工程通知響應處理程式一樣被觸發）：

public class TestNotificationHandler(INotificationService notificationService) : INotificationHandler<TestNotification>
{
    public Task Handle(TestNotification notification, CancellationToken cancellationToken)
    {
        notificationService.Show("Notification",
            $"模塊【SlugifyString】Notification處理程式：Args = {notification.Args}, Now = {DateTime.Now}");
        return Task.CompletedTask;
    }
}

幾個響應處理程式類定義類似：收到請求時，返回格式化字元串；收到通知時，彈出提示表明當前是哪個位置收到的通知，便於演示效果。

5. 請求和通知演示

觸發操作我們寫在模塊【CodeWF.Tools.Modules.SlugifyString】中，在模塊的ViewModel類里通過依賴註入獲取請求和通知的發送者實例ISender和IPublisher：

using Unit = System.Reactive.Unit;

namespace CodeWF.Tools.Modules.SlugifyString.ViewModels;

public class SlugifyViewModel : ViewModelBase
{
    // 省略別名轉換相關邏輯代碼，源碼文末查看
    
    private readonly INotificationService _notificationService;
    private readonly IClipboardService? _clipboardService;
    private readonly ITranslationService? _translationService;

    public SlugifyViewModel(INotificationService notificationService, IClipboardService clipboardService,
        ITranslationService translationService, ISender sender, IPublisher publisher) : base(sender, publisher)
    {
        _notificationService = notificationService;
        _clipboardService = clipboardService;
        _translationService = translationService;
        KindChanged = ReactiveCommand.Create<TranslationKind>(OnKindChanged);
    }


    public async Task ExecuteMediatRRequestAsync()
    {
        var result = Sender.Send(new TestRequest() { Args = To });
        _notificationService.Show("MediatR", $"收到響應：{result.Result}");
    }

    public async Task ExecuteMediatRNotificationAsync()
    {
        await Publisher.Publish(new TestNotification() { Args = To });
    }

}

點擊測試MediatR-Request按鈕觸發調用ISender.Send發出請求並得到響應，通過點擊測試MediatR-Notification按鈕觸發調用IPublisher.Publish發出通知。

請求效果：

看上面的請求效果：雖然在主工程和模塊工程都註冊了一個響應，但只有主工程被觸發。

通知效果：

在主工程和模塊工程都註冊了一個通知響應，所以兩個處理程式都彈出了提示。

6. 總結

為什麼使用MediatR，而未使用Prism的事件聚合器？

站長開發工具做了線上版(https://blazor.dotnet9.com)，也做了跨平臺桌面版本（AvaloniaUI），兩個版本使用MediatR可以復用大部分事件代碼。

CQRS or DDD?

這節直接複製MediatR 在 .NET 應用中的實踐 - 明志唯新 (yimingzhi.net)，大家應該可以學到些什麼：

軟體開發發展到今天，模式和理念不斷在架構中刷新：從分散式到微服務，再到雲原生 ……。時代對一個程式員，尤其是服務端程式員，提出的要求越來越高。DDD（領域驅動設計）在微服務架構中一再被提及，甚至有人提出這是必須項！

實施一個完美的 DDD 還是有難度的，現實中奮戰在一線的 CRUD 程式員還是不少。那麼在 CRUD 和 DDD 之間我們是否還有緩衝區呢？MediatR 的作者曾經也撰文討論過這個問題，我很認同他的基本觀點：設計是為應用服務的，不能為了 DDD 而 DDD。

CQRS 的全稱是："Command and Query Responsibility Segregation"，直譯過來就是命令與查詢責任分離，可以通俗的理解為 讀寫分離。

微軟的官方文檔中對此做過如下陳述：

CQRS 命令和查詢責任分離數據存儲的讀取和更新操作分離的模式。 在應用程式中實現 CQRS 可以最大程度地提高其性能、可伸縮性和安全性。 通過遷移到 CQRS 而創建的靈活性使系統能夠隨著時間的推移更好地發展，並防止更新命令在域級別導致合併衝突。

微軟也給出了相應的隔離模型解決方案：

CQRS 使用命令來更新數據，使用查詢來讀取數據，將讀取和寫入 分離到不同的 模型中。

• 命令應基於任務，而不是以數據為中心。
• 命令可以放置在隊列中進行非同步處理，而不是同步處理。
• 查詢從不修改資料庫。 查詢返回的 DTO 不封裝任何域知識。

CQRS 的好處包括：

• 獨立縮放: CQRS 允許讀取和寫入工作負載獨立縮放，這可能會減少鎖爭用。
• 優化的數據架構: 讀取端可使用針對查詢優化的架構，寫入端可使用針對更新優化的架構。
• 安全性: 更輕鬆地確保僅正確的域實體對數據執行寫入操作。
• 關註點分離: 分離讀取和寫入端可使模型更易維護且更靈活。 大多數複雜的業務邏輯被分到寫模型。 讀模型會變得相對簡單。
• 查詢更簡單: 通過將具體化視圖存儲在讀取資料庫中，應用程式可在查詢時避免複雜聯接。

有了 MediatR 我們可以在應用中輕鬆實現 CQRS:

• IRequest<> 的消息名稱以 Command 為結尾的是命令，其對應的 Handler 執行寫任務
• IRequest<> 的消息名稱以 Query 為結尾的是查詢，其對應的 Handler 執行讀數據

結束語

MediatR 是一個簡單的中介者實現，可以極大降低我們的應用複雜度，也能夠使得我們一路從 CRUD 到 CQRS 到 DDD 進行逐級演進。畢竟我們是生活在現實中的人，不能罔顧商業現實，純粹一味追求技術。

商業技術的演進，應該是一路持續的改革而不是來一場革命。疫情總有反覆，但是我們得活著，相對輕鬆的活著！

參考

文中示例寫了主要代碼，但可能缺失部分細節，源碼鏈接如下，歡迎留言交流。

參考文章：MediatR 在 .NET 應用中的實踐

本文源碼：Github