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.
If you have followed my Fat Controller CQRS Diet
series, you will see that I use the mediator pattern.
More specifically I use MediatR
library in all the code examples.
I recently gave a talk at CodeMash 2017
with the same title. It went a bit more in depth about why and where I use the mediator pattern.
I want to decouple my application from the framework I’m using. The mediator pattern is one way of achieving that.
My code should be be my code. Not littered through framework code.
Generally, I don’t want to have any dependencies on MVC, Web API, WFP, WinForm or whatever the top layer framework is that I’m using.
If I’m using ASP.NET MVC or Web API as my frontend to expose my application, I want to leverage it for what it’s good at. The various aspects of the framework such as routing, view rendering, serialization (possibly) but without coupling my code to those.
Context is King
I generally don’t think in black or white when it comes to developing software. Context is always king.
Making decisions around context is really important.
How do you know if you should decouple yourself from your framework?
Are you creating an application that is likely going to be used for many many years?
Does it have high value to it’s users?
Is it only throw away to validate an idea and going to last 6 months?
How large is the application, in terms of length of time to develop? Could you rewrite it quickly?
Are you developing an application with a web interface or are you developing a web application?
All these questions and many more really matter in determining how far you should decouple from your web framework.
I love hearing your comments, questions and feedback! Please post a comments or on Twitter.