Vanilla DI is one of the implementation approach of Dependency Injection. And also, Vanilla DI is an approach of design.
This approach have the following advantages:
- Extremely simple
- Extremely easy to use
- Zero dependency
- Good debuggability
- Good readability for beginners
- Good portability for most languages
- Good way to layered architecture
For fairness, this approach have the following disadvantages:
- Can't follow completly to DRY
- Maintainability highly depend to design skill
But using Vanilla DI is still a good choice for many situations.
Concept
This approach is extremely simple; Inject depended components via the dependent constructor.
You can achieve it by writing code like the following for each dependent components:
// These are depended components.
class X {}
class Y {}
// This is a dependent component.
class Z {
constructor(dependency) {
const {x, y} = dependency;
this.x = x;
this.y = y;
}
doSomething() {
// Do something with this.x and this.y.
}
}
// All dependency should be injected when
// the dependent component is constructing.
const z = new Z({
x: new X(),
y: new Y(),
});
z.doSomething();That's all.
Key Things
There are 2 key things to be use easily this approach:
- Command-Query Separation
- Single Responsibility Prinsible
Command-Query Separation
Command-Query Separation (CQS) is a principle of design. Vanilla DI become hard to use if you don't follow the principle.
Single Responsibility Prinsiple
Single Responsibility Principle (SRP) is also a principle of design. Vanilla DI become hard to maintain if you don't follow the principle.
FQA
X is the de facto library of Y language. So we should use it, right?
Yes and no. It completely depends to your situation.
For example, you should use some DI libraries if the library is already used in your project. For another example, you should not use any DI libraries if the project is across many languages and project members are not expert for each languages.
It means, using a DI liberary is not always the best solution. Don't be afraid to be away from DI libraries.
Contributing
I started the project on https://github.com/vanilla-manifesto/vanilla-di-manifesto. Any suggetions are welcome. Feel free to open issues to discuss about Vanilla DI.
