CleanArch.DevKit.Messaging 1.1.0

CleanArch.DevKit.Messaging

Bus pub/sub in-process avec abonnement runtime. Pour les composants qui s'enregistrent/se désenregistrent dynamiquement (UI, view models, modules).

Rôle

IMessenger complète INotification de Mediator.Core. Les notifications du médiateur sont des handlers connus à la compilation et inscrits dans le DI — leur durée de vie est gérée par le conteneur. Les messages d'IMessenger sont au contraire abonnés au runtime : un composant s'inscrit dynamiquement (ex. au démarrage d'un view model) et se désinscrit en libérant son token IDisposable.

Deux implémentations sont fournies : Messenger (références fortes, défaut) et WeakMessenger (références faibles, plus tolérant en MVVM).

Installation

dotnet add package CleanArch.DevKit.Messaging

Aucune dépendance NuGet hors Microsoft.Extensions.DependencyInjection.Abstractions.

Fonctionnalités

• S'abonner à un type de message (Subscribe / SubscribeAsync)
• Envoyer un message (Send / SendAsync)
• Désabonner automatiquement via IDisposable
• Choisir Messenger (références fortes) ou WeakMessenger (références faibles)

S'abonner à un message

Subscribe<TMessage> retourne un IDisposable ; conserver ce token et le disposer pour désabonner :

public sealed record UserSignedIn(string Email);

public sealed class HeaderViewModel : IDisposable
{
    private readonly IDisposable _subscription;

    public HeaderViewModel(IMessenger messenger)
    {
        _subscription = messenger.Subscribe<UserSignedIn>(OnUserSignedIn);
    }

    private void OnUserSignedIn(UserSignedIn evt)
    {
        // mettre à jour l'UI
    }

    public void Dispose() => _subscription.Dispose();
}

Pour un handler asynchrone :

_subscription = messenger.SubscribeAsync<UserSignedIn>(async (evt, ct) =>
{
    await audit.RecordAsync(evt, ct);
});

Envoyer un message

Send est synchrone et n'invoque que les abonnés synchrones ; SendAsync invoque les abonnés sync (d'abord) puis async (séquentiellement) :

messenger.Send(new UserSignedIn("alice@example.com"));

await messenger.SendAsync(new UserSignedIn("alice@example.com"), ct);

Si aucun abonné n'est inscrit pour le type, l'appel est silencieux (pas d'exception).

Désabonner

La disposition du token retire le handler. Le pattern typique en MVVM/UI : implémenter IDisposable sur le view model et disposer dans le code-behind / le conteneur de fenêtre :

using (var vm = new HeaderViewModel(messenger))
{
    messenger.Send(new UserSignedIn("alice@example.com"));
    // ...
}
// vm est disposé → le handler n'est plus appelé
messenger.Send(new UserSignedIn("bob@example.com")); // pas d'effet

Choisir entre Messenger et WeakMessenger

Les deux implémentations sont enregistrées en singleton sous IMessenger — n'en utiliser qu'une seule par container :

services.AddMessenger();     // Messenger — références fortes
// OU
services.AddWeakMessenger(); // WeakMessenger — références faibles

Piège WeakMessenger : un handler en lambda avec capture de variables (messenger.Subscribe<T>(msg => myVar.Do(...))) crée un objet closure dont seul WeakMessenger détient une référence. Le GC peut alors le collecter et le handler arrête silencieusement de fonctionner. Pour ce cas : soit garder une référence forte sur le token IDisposable, soit utiliser Messenger à la place.

IMessenger vs INotification (Mediator)