In my Fat Controller CQRS Diet series, I’ve shown the mediator pattern and the MediatR library. After a recent discussion with Reid Evans, he made me realize I haven’t really described the trade-offs. This post is going to focus on trade-offs and an alternative to using the mediator pattern. If you’re new to this series, here are earlier posts to get you up to speed:
Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.For me the purpose of using the mediator pattern is to limit the coupling between integration boundaries. Those boundaries in my applications are typically the Web/UI Framework and my core application. This means I’ll have my controllers take a dependency on the mediator and not my core application.
Runtime ResolutionThe downside to this that there is no compile time type checking. When the mediator is invoked at runtime, it could fail to send the request if there is no handler defined. In the code example above, if there is no
IAsyncRequestHandler<Home, List<Album>>then an exception will be thrown on