The business case for a DI framework
Every Architecture Design decision should be based on one or more Non-Functional requirements. Each Non-Functional requirement in its case should be based on a business need. Recently I asked myself what are the business needs for using a dependency injection (DI) framework?
Which visible, tangible benefit would be reached using a DI framework? This blog post describes the arguments we used to successfully convince management.
Dependency Injection Framework
A dependency injection framework is a software module that manages the dependencies of your application. Dependency Injection is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. An excellent discussion on how to use a DI container can be found here by Uncle Bob. Inversion of Control is one of the SOLID design principles. There are many types of dependency injection frameworks, for a comparison take a look at this and this blog post from Andrey Shchekin.
Convincing management
Recently at LetsGrow we started using a dependency injection or DI framework for the LetsGrow.com platform. We are using Test Driven Development (TDD) and using a DI framework seemed to be the next logical step. This would remove the implementation of several builder patterns and would make implementing tests easier. It would also make the LetsGrow.com platform more flexible. Although these benefits were clear to me, I had a hard time convincing management of the business benefits of a DI framework.
Who makes the design decision?
One could argue that the design decision of using a DI Framework should be made by an architect. I think that introducing a DI framework also comes at a cost. Surely the benefits will be greater in the long run, but the development of new functionality will be slower during the introduction of a DI framework. The development team has to learn how to use such a framework, some existing code will change with no visible benefit for the user of the application. Therefore, I think that such a decision should be made in cooperation with management.
Business benefits
The primary benefits of using a DI framework are that it makes the source code of an application easier to understand, to maintain and to extend. Using a DI framework will reduce the amount of source code which will decrease the time it takes to implement new functionality in your application. In the long-term, this results in reduced maintenance costs, lower bug rates and thus increased customer satisfaction.
Secondary benefits are that configuration of an application will be more obvious as it sits in a central place. All instances of objects will be created the same way (consistency). When using a DI framework it becomes possible to switch implementations at run-time. For end-to-end tests it becomes possible to replace key components of the application with fake implementations.
Risks
We also looked at the possible risks of introducing a DI framework. We identified the following risks:
- increased memory usage
- performance overhead
- complexity in configuration
- less transparent source code
After some research we found that there was indeed an increase in memory and some performance overhead but they were marginal. I think that everyone that wants to use a DI framework should also do this research themselves because this could differ per application.
Complexity in configuration is a real risk. If you describe each dependency of each class in the configuration file, the configuration file becomes too large and complex. Only these dependencies that should be managed by the framework should be described using the configuration file. Hartmut Wilms also discusses this risk in this blog post. The last risk, less transparent source code we think will be temporary. Developers will have to get used to using a DI framework and the fact that the DI framework takes care of creating instances of objects.
Conclusion
My conclusion is that with the arguments mentioned in this post you should have no trouble convincing management of the business benefits of using a DI framework for your application. If you have more benefits or convinced your organization using a totally different arguments let me know. I would love to hear it.