Skip to content

Dependency Container

This article explains the concept behind IdleKit's Dependency Container. For implementation specifics please visit the pages in the What's next section.

What is the Dependency Container

The Dependency Container (IContainer) is a system built to futher realize the concepts of Inversion of Control and Dependency Injection. It is used to manage the object composition and dependency in IdleKit. This simplifies the codebase, reduces the need for boilerplate code and allows the lifetime of an object to be followed more easily.

Inversion of Control and Dependency Injection

Inversion of Control (IoC) brings the advantage of decoupling the client application from the modules that it uses. It defines contracts for modules so the modules do not need to know about the other parts of the system. This prevents side effects when replacing a module. Dependency Injection (DI) is a technique of IoC.

  • IoC is a generic term meaning rather than having the client application directly call the methods in a framework, the framework calls implementations provided by the application.
  • DI is a form of IoC where implementations are passed into an object through constructors/setters/service lookups, which the object will 'depend' on in order to behave correctly.
  • IoC without DI: an example would be the Template Method pattern because the implementation can only be changed through sub-classing.
  • IoC with DI is designed to make use of DI and can define interfaces to make it easy to pass in the implementations.
  • IoC with Containers are DI frameworks that can work outside of the programming language. In some you can configure which implementations to use in metadata files (e.g. XML) which are less invasive. With some you can do IoC that would normally be impossible like inject an implementation at the exact points in execution.

IdleKit with Dependency Container

The IdleKit Dependency Container allows IdleKit to be extendable and portable. Users can swap out any piece of an IdleKit module and replace it with their own implementation without any harm to the system. The Container with DI system can define and inject dependent modules to the user object at runtime based on contracts. This makes the whole process of managing the dependent modules much simpler and streamlined.

What's next?

Please refer to the following pages for specific topics about the Dependency Container: * Components * Integration * Cheatsheet

For more detailed information about IoC, DI and Containers please see the following: * Stack Overflow * Wikipedia * Martin Fowler