Mediator Pattern in ASP .NET Core 3.1

The mediator pattern is a behavioral design pattern that helps to reduce chaotic dependencies between objects. The main goal is to disallow direct communication between the objects and instead force them to communicate only via the mediator.

This post is part of “Microservice Series - From Zero to Hero”.

Problem

Services or classes often have several dependencies on other classes and you quickly end up with a big chaos of dependencies. The mediator pattern serves as an organizer and calls all needed services. No service has a dependency on another one, only on the mediator.

You can see the mediator pattern also in real life. Think about a big airport like JFK with many arriving and departing planes. They all need to be coordinated to avoid crashes. It would be impossible for a plan to talk to all other planes. Instead, they call the tower, their mediator, and the tower talks to all planes and organizes who goes where.

Advantages and Disadvantages of the Mediator Pattern

The mediator pattern brings a couple of advantages:

• Less coupling: Since the classes don’t have dependencies on each other, they are less coupled.
• Easier reuse: Fewer dependencies also help to reuse classes.
• Single Responsibility Principle: The services don’t have any logic to call other services, therefore they only do one thing.
• Open/closed principle: Adding new mediators can be done without changing the existing code.

There is also one big disadvantage of the mediator pattern:

• The mediator can become such a crucial factor in your application that it is called a “god class”.

Implementation of the Mediator Pattern

You can find the code of  the finished demo on GitHub.

To use the mediator pattern in .NET, I am using the MediatR NuGet package, which helps to call the services.

Installing MediatR

I am installing the MediatR and the MediatR.Extensions.Microsoft.DependencyInjection in my Api project. In the Startup class, I registered my mediators using:

I can do this because the controllers are in the same project. In the OrderApi, I am also using the ICustomerNameUpdateService interface as a mediator. Therefore, I also have to register it.

Now, I can use the IMediator object with dependency injection in my controllers.

Using the Mediator pattern

Every call consists of a request and a handler. The request is sent to the handler which processes this request. A request could be a new object which should be saved in the database or an id of an object which should be retrieved. I am using CQRS, therefore my requests are either a query for read operations or a command for a write operation.

In the OrderController, I have the Order method which will create a new Order object. To create the Order, I create a CreateOrderCommand and map the Order from the post request to the Order of the CreateOrderCommandObject. Then I use the Send method of the mediator.

The request (or query and command in my case) inherit from the IRequest<T> interface where T indicates the return value. If you don’t have a return value, then inherit from IRequest.

The send method sends the object to the CreateOrderCommmandHandler. The handler inherits from IRequestHandler<TRequest, TResponse> and implements a Handle method. This Handle method processes the CreateOrderCommand. In this case, it calls the AddAsync method of the repository and passes the Order.

If you don’t have a return value, the handler inherits from IRequestHandler<TRequest>.

Conclusion

The mediator pattern is a great pattern to reduce the dependencies within your application which helps you to reuse your components and also to keep the Single Responsible Principle. I showed I implemented it in my ASP .NET Core 3.1 microservices using the MediatR NuGet package.

In my next post, I will implement RabbitMQ which enables my microservices to exchange data in a decoupled asynchronous way.

You can find the code of the finished demo on GitHub.

This post is part of “Microservice Series - From Zero to Hero”.