The website content discusses the implementation of an Inversion of Control (IoC) container with dependency injection in JavaScript, particularly for Node.js applications, and provides examples of how to create and use such a container to improve code decoupling, testability, and maintainability.
Abstract
The article titled "Creating an IoC Container with dependency injection in JavaScript" explains the utility of IoC containers in managing object dependencies in applications, such as those built with Node.js. It emphasizes the benefits of using containers for decoupling code, facilitating testing, and simplifying the replacement of classes. The author provides a practical example of a container that supports object creation, singletons, and dependency resolution, demonstrating how dependencies are injected into constructors. The article also illustrates how to integrate the container with Express routes, allowing for easy access to class instances or objects within route handlers. The author concludes by encouraging developers to consider building a custom IoC container tailored to their specific needs, rather than relying on complex third-party libraries. A link to the example container's GitHub repository is provided for further exploration.
Opinions
The author believes that IoC containers are a convenient tool for resource management and object resolution within applications.
Dependency injection and IoC are presented as beneficial for writing more testable and maintainable code.
The author suggests that the concepts of IoC, dependency injection, and containers might seem intimidating but are not as complex as they appear.
The article promotes the idea that a simple, custom-built IoC container can be sufficient for many use cases without the need for extensive third-party solutions.
The author's examples and explanations aim to demystify IoC and dependency injection, making them more accessible to developers.
Creating an IoC Container with dependency injection in JavaScript
When building application in, for example Node.js it‘s rather convenient to have some kind of container where resources or routes can access or resolve other objects/classes. This is where an “Inversion of control”-container comes handy.
Using containers and “inversion of control” helps you decouple your code, it also makes it easier to test, especially when writing unit tests. I will also make your life a lot easier, if you, at some point want to replace some class.
Below is an example of a container, which has support for object creation, singletons, regular objects (which can be used for example configuration) and it also resolves dependencies.
Hearing about inversion of control, dependency injection, factory and container can be quite scary, but it’s not rocket science, that’s what I wanted to show with this example.
With the container below you can register objects, singleton classes and normal classes. As third parameter you can specify dependencies for this class (dependencies must also be registered in the container) Those dependencies is then created and injected into the constructor when the requested class is being requested.
When requesting ‘user’ from the container, the logger will be resolved and injected into the constructor. (Constructor injection). (And the logger class will have the config object injected)
Example of a basic IoC container with constructor injection
Using in Express routes
Your express routes may do a bit of business logic or might need access to other class instances or objects for other reasons. Anyway, Express 4 exposes a nice way to pass your container to the routes.
You simply call the set-method on your app.
The container can later be retrieved in the routes by using the get-method on the request object.
Just an example
This is just an example of one way to implement a basic IoC Container with support for dependency injection.
You might create a container without inversion of control or dependency injection, where you just register the class definition and then take care of the object creation your self.
You might need to implement support to pass parameters when retrieving an object or you maybe need method injection.
My point is that you might not need a third party library that solves every aspect of IoC, injection and object creation, you might be just fine with running your own container, designed for you needs, simple and fast.