The Mediator Pattern In C# .NET – Part 3 – MediatR Library

This is Part 3 of a series on using the Mediator Pattern in C# .NET. You’ve probably missed out on some important stuff if you’re starting here so make sure to head back and read Part 1 before reading on!

The Mediator Pattern In C# .NET

Part 1 – What’s A Mediator?
Part 2 – Roll Your Own
Part 3 – MediatR

MediatR Library

The MediatR library describes itself as “Simple, unambitious mediator implementation in .NET”. In particular, I like the word “Unambitious” being used. It’s somewhat refreshing in a world of Hacker News posts that claim to be releasing a library that will change the way we write code forever. You may also recognize the author of MediatR as Jimmy Bogard who also maintains AutoMapper!

MediatR is essentially a library that allows in process messaging – which in turn allows you to follow the Mediator Pattern! Easy! Let’s get started

Installing MediatR

The first thing we need to do is install the MediatR nuget package. So from your package manager console run :

Install-Package MediatR

We also need to install a package that allows us to use the inbuilt IOC container in .NET Core to our advantage (We’ll see more of that shortly). So also install the following package :

Install-Package MediatR.Extensions.Microsoft.DependencyInjection

Finally we open up our startup.cs file. In our ConfigureServices method, we need to add in a call to register all of MediatR’s dependencies.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMediatR(Assembly.GetExecutingAssembly());
    //Other injected services. 
}

Creating Our Handlers

The first thing to note is that MediatR can be either do “send and receive” type messages, or it can do a “broadcast” type message. Taking our example from our previous article in the series, we are doing a more broadcast style of message (And a pretty simple one at that). Let’s just stick with that for now.

In our original example, we weren’t passing through any information to our handlers, but in reality we are likely passing through some data. Basically a message if we think about traditional messaging systems. Let’s go ahead and just create a blank object that inherits from INotification  (An inbuilt type of MediatR).

public class NotificationMessage : INotification
{
    public string NotifyText { get; set; }
}

Next we need handlers for the messages. That’s easy too, we just inherit from INotificationHandler  and go from there!

public class Notifier1 : INotificationHandler<NotificationMessage>
{
    public Task Handle(NotificationMessage notification, CancellationToken cancellationToken)
    {
        Debug.WriteLine($"Debugging from Notifier 1. Message  : {notification.NotifyText} ");
        return Task.CompletedTask;
    }
}

public class Notifier2 : INotificationHandler<NotificationMessage>
{
    public Task Handle(NotificationMessage notification, CancellationToken cancellationToken)
    {
        Debug.WriteLine($"Debugging from Notifier 2. Message  : {notification.NotifyText} ");
        return Task.CompletedTask;
    }
}

Super simple! We also don’t need to register these handlers anywhere, the initial line we added to our ConfigureServices method means that MediatR finds all handlers within the assembly and registers them correctly.

Creating Our Mediator Service

Now here’s the thing. We *can* just inject in the inbuilt IMediator interface everywhere and publish messages directly. Personally I’m not a huge fan because it’s basically telling everywhere “by the way, we use MediatR”. I prefer to abstract things away a little bit.

If we take our Mediator Service from the previous article, let’s just modify it a bit. Instead let’s build it like so :

public interface INotifierMediatorService
{
    void Notify(string notifyText);
}

public class NotifierMediatorService : INotifierMediatorService
{
    private readonly IMediator _mediator;

    public NotifierMediatorService(IMediator mediator)
    {
        _mediator = mediator;
    }

    public void Notify(string notifyText)
    {
        _mediator.Publish(new NotificationMessage { NotifyText = notifyText });
    }
}

So we have a NotifierService that still uses the IMediator class under the hood, but it means if we ever swap out libraries or change how we do notifications, only this class changes.

Because we have created a new service, we do need to remember to add the following line to our ConfigureServices method in our startup.cs file :

services.AddTransient<INotifierMediatorService, NotifierMediatorService>();

Using Our Notifier Mediator Service

Let’s use a super simple controller to run things. Again this is basically taken from Part 2 in this series and just modified a tiny bit to work with passing through notify text.

public class HomeController : ControllerBase
{
    private readonly INotifierMediatorService _notifierMediatorService;

    public HomeController(INotifierMediatorService notifierMediatorService)
    {
        _notifierMediatorService = notifierMediatorService;
    }

    [HttpGet("")]
    public ActionResult<string> NotifyAll()
    {
        _notifierMediatorService.Notify("This is a test notification");
        return "Completed";
    }
}

Running all of this and opening up our debug panel we can see :

Debugging from Notifier 1. Message  : This is a test notification 
Debugging from Notifier 2. Message  : This is a test notification

Woo! Literally a 5 minute job to set up a completely in memory messaging system!

Final Thoughts On The Mediator Pattern

As we made our way through these 3 posts, it’s probably morphed a bit from the “Mediator Pattern” to “In Process Messaging”. But going back to our key bullet points from Part 1 :

• It’s an object that encapsulates how objects interact. So it can obviously handle passing on “messages” between objects.
• It promotes loose coupling by not having objects refer to each other, but instead to the mediator. So they pass the messages to the mediator, who will pass it on to the right person.

We can see that In Process Messaging is actually just an “implementation” of the mediator pattern. As long as we are promoting loose coupling through a “mediator” class that can pass data back and forth so that the caller doesn’t need to know how things are being handled (By whom and by how many handlers), then we can say we are implementing the Mediator Pattern.