Secret ingredients to quality software


Do you use your IOC container to Inject Dependencies – and not as a singleton container

Created on 24 Oct 2016 | Last updated by Brendan Richards on 24 Oct 2016 11:02 PM (over 4 years ago)

A common practice we see when developers start to use IOC containers is that the IOC container becomes a central service and configuration repository that all the components across the project become dependent upon.

Using an IOC container in this manner can bring advantages such as centralised configuration and dependency lifecycle and scope managment. If implemented correctly, however, your classes can benefit from the above without any direct dependency on the IOC container itself.

IOC badexample

Figure: Bad Example - the dependency is manually fetched from the IOC container, This class now has a hard dependency on your IOC container

IOC GoodExample

Figure: Good example - The dependency is enforced via a constuctor parameter. The class does not need to know anything about the IOC container being used and can potentially be reused in different contexts and with different IOC containers.

For more information and insight on IOC usage, read the following:

Brendan RichardsBrendan Richards

We open source. This page is on GitHub