Alex KlausFull Stack Developer  |  Architect  |  Scrum Master
Is Mediator/MediatR still cool?
01 January 2020

Don't ruin the Mediator/MediatR

Arguably, the Mediator pattern has become cool among the .NET devs when Jimmy Bogard released MediatR library 4 years ago. That library made words ”Mediator” and ”MediatR” interchangeable in the devs’ lexicon. And as usual, trendy tools get often misused and applied without a second thought (because ”C’mon, it’s MediatR!”).

Here I’m playing devil’s advocate and look closely at its pros and cons. Is it still beneficial for modern .NET Core projects to bring MediatR?

What problems Mediator solves?

The Mediator pattern defines an object that encapsulates how a set of objects interacts. It solves 2 problems:

  1. Tight coupling between interacting objects.
  2. Changing the interaction between objects independently.

It’s achieved by adding a separate object (mediator) and delegating the interaction to it. So for interacting objects A and B, where A triggers an action and B acts on it, B wouldn’t know what triggers the action and A wouldn’t know what happens when the action is triggered.

A simplified C# example would be:

public class ClassA
{
	private IMediator _mediator;

	public ClassA (IMediator mediator)
	{
		// ...
	}
	public void Process()
	{
		// Interaction with another object via Mediator
		_mediator.Send(new Ping());
	}
}

public class ClassB : IRequestHandler<Ping>
{
	public void Handle(Ping request)
	{
		// Act on command/requests
	}
}

Explicit Dependencies Principle

The code sample above highlights the main problem of the Mediator — violation of the Explicit Dependencies Principle, where the class should clearly indicate what it needs in order to function. This would make your code more self-documenting and your coding contracts more user-friendly.

Hiding dependencies in Mediator creates room for problems like:

  • Run-time errors on execution of a method.

    E.g. on sending a request with no or broken handler. Alternatively, for injected dependencies it could be a run-time error on creating a class, which is still better as it fails sooner.

  • Harder to trace dependencies.

    Devs maintaining the code have to understand the naming conventions, how the call stack for request handlers looks like, etc. in order to resolve dependencies. It may increase maintenance costs.

These problems may look familiar. Remember the Service Locator, which was cool in 2004 and later, in 2010, became an anti-pattern due to similar reasons? Will the Mediator follow this path? Time will tell.

Solving problems in .NET without Mediator

Dependency injection

.NET devs already use DI/IoC and the implementation of interacting objects is decoupled, as the objects refer to the contracts (interfaces).

public class MyClass
{
	public MyClass (IFoo foo, IBoo boo, IMoo moo)
	{
		...
	}
}

Tight coupling is not that acute issue in the .NET. Of course, the coupling can be looser after adding an extra abstraction layer (e.g. Mediator), but the code above meets the Explicit Dependencies Principle.

Another bonus — constructor injection makes violations of the Single Responsibility Principle glaringly obvious. Having too many parameters in a constructor is usually a red flag indicating a need to refactor.

The DI allows changing the interaction between objects almost at the same level of independence as the Mediator does. Here you trade dependency on commands for dependency on interface methods.

DI constructor madness in controllers

Perhaps, we can reduce number of constructor parameters almost everywhere in the .NET project apart from ASP.NET controllers. We craft controllers to reflect the route, which needs to be intuitive for the consumer. It may lead to bundling up way too many services and repositories to be injected in the constructor.

public DashboardController(
    IProductQueryService productQueryService,
    IRelatedProductQueryService relatedProductQueryService,
    IOrderQueryService orderQueryService,
    IOrderHistoryQueryService orderHistoryQueryService,
    ICustomerQueryService customerQueryService,
    IUserProfileQueryService userProfileQueryService,
    ISupportService supportService,
    ILogger logger
)

In addition to that, controller methods often just call a single method of an injected class. It adds overhead for WebAPI requests, where on each call the controller has to construct too many unnecessary objects.

Fortunately, .NET Core provides FromServices, allowing injecting a service directly into an action method without using constructor injection. It makes controllers quite concise.

[HttpGet]
public Task<IActionResult> CurrentTime([FromServices] IDateTime dateTime)
{
    var time = $"Current server time: {dateTime.Now}";
    return Ok(time);
}

Though, FromServices attribute can be used everywhere in the project, it’s hard to justify its existence anywhere apart from controllers.

I reckon, the above shows that a reasonably clean implementation can be achieved in .NET without involving the Mediator.

What does the Mediator have to do with CQRS?

Some devs believe that a proper CQRS can be implemented only with the Mediator.

Well… Not really. They are quite independent concepts. You definitely can use a Mediator with CQRS, and probably a half-dozen other useful software patterns with both.

If interested in a detailed comparison of CQRS and Mediator with diagrams, check out this post.

What Jimmy Bogard says about MediatR?

Jimmy Bogard, the author of MediatR, has been working in consulting for many years and crafted MediatR to his needs. He blogs a lot about it at jimmybogard.com and speaks at various conferences. In this video (NDC Sydney 2016) he outlined his reasoning behind bringing the MediatR into his projects:

My basic philosophy was I will not introduce any sort of pattern or any sort of structure into my system until the code tells me that it’s needed.

He, as many other consultants, had to develop a solution while many business processes and domain entities/aggregates are still being defined. In this case MediatR does help to create granular operations with nice decoupling.

The story would be different for product-oriented teams, where understanding the domain and reflecting it in the code is paramount.

When to use Mediator/MediatR in .NET?

No doubt that the code can be well-structured and easy to read/maintain without the Mediator (meeting the SOLID principles, implementing CQRS, etc.). However, there are cases for using the Mediator/MediatR:

1. Complex objects interaction

When you do need to trigger dozens of commands and notifications, then doing so with just DI/IoC would lead to ”constructor madness” (dozens parameters for all the interfaces executing commands and notifications).

As I stated above, ideally, seeing excessive dependencies should incentify rethinking of the dependencies. But if nothing can be done, then the Mediator will come to the rescue.

2. Need in MediatR’s features

Nowadays MediatR supplies out-of-the-box commands/requests, notifications and behaviours, which come in handy for building pipelines (e.g. for validations). If adoption of a pure Mediator is not beneficial for the project, then the whole MediatR bundle can win you over.

3. Development where a lot remains unknown (consulting)

Where business processes and domain entities/aggregates remain murky and you need to deliver the code, then MediatR does help in creating granular operations and decoupling the code.

It can be quite common among consultants. And there are consulting companies out there that have mastered the MediatR approach to a high degree with all conventions, test practices, rules, etc. in place. It does require a preparation for the team and some supervision at the beginning to mitigate the Mediator’s issues, but then the team may benefit from using it.

Check out Clean Architecture from Jason Taylor on GitHub as one of examples with a neat adoption of MediatR.

Conclusion

Today, implementation of the Mediator pattern provides subtle benefits to .NET projects due to existing rich capabilities of the .NET. And considering a rapid pace of evolution in .NET, the current benefits may become even less noticeable in the future.

However, the MediatR library is a slightly different case, as it comes in a bundle with other useful features related to the Mediator pattern. The library gives devs a neat way to implement notifications, good standard for error handling, plays well with Fluent Validations, etc. It’ll remain useful for the devs as long as it evolve along with the .NET.

Do you know other examples where Mediator/MediatR is a good fit? Other thoughts? Have your say in the comments below, on Reddit thread or on Twitter.