I’m a big fan of the Inversion of Control(IoC) pattern and how Dependency Injection(DI) frameworks can help you implement this pattern. IoC was really a gamechanger to me and had a lot of impact on the way I build and architect my applications.
Note: As I’m doing more and more functional programming, the need to use a DI framework is going away, but that’s something to discuss in another blog post
Unfortunately something I see a lot in applications that use a DI framework is something I call “dependencies diarrhoea”.
Let’s have a look at an example ASP.NET MVC controller to illustrate the problem:
So what’s the problem here? Without even looking at the full implementation, it should be clear that this class is violating the ‘Single Responsibility Principle’ and is doing too much in one class. This not only makes it harder to reason about this class, but also makes it a lot harder to test. There is no fun in mocking out lots of dependencies just to test a small piece of functionality.
One solution could be to use composition and create smaller components that do one thing and one thing well. This should already help to reduce the number of dependencies.
One disadvantage of using smaller components is that you sometimes end with large object hierarchies with a lot of coupling between these components. A solution for this could be the usage of the Publish/Subscribe pattern. You only focus on the dependencies that are directly related to the controller and for the other stuff you throw out an event that can be picked up by other components inside your system. This is a great way to further reduce the coupling inside your system.
