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, which simplifies the codebase, reduces the need for boilerplate code, and allows the objects' lifetime to be tracked better.
Inversion of Control and Dependency Injection
Inversion of Control IoC brings the advantage of decoupling the client application and the modules that it uses, defining contracts for modules so the modules do not need to know about the other parts of the system, and preventing side effects when replacing a module. Dependency Injection DI is a technique of IoC. The following is a brief overview of the definition of IoC, DI, and Container.
- 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 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.
For more detailed information, please see the following:
IdleKit with Dependency Container
The IdleKit Dependency Container allows IdleKit to be extendable and portable as users can swap out any piece of IdleKit module and replace it with their own implementation without any harm to the system. In addition, 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.
e.g: IStage utilizing the IContainer and IResolver to fulfill its dependency.
//The IActionService is first bound to the container.
public class IKInstaller : Installer, IIKInstaller
{
protected virtual void BindServices()
{
_binder.Bind<IActionService>().To<ActionService>().AsSingleton().Conclude();
}
}
//When the Stage is loaded, IActionService is injected into the Stage with the IResolver.
public class Stage : IStage, IInjectable
{
...
public virtual void Inject(IResolver resolver)
{
...
_actionService = resolver.Resolve<IActionService>();
...
}
}
What's next?
Please refer to the following pages for specific topics about the Dependency Container: