Struggling to navigate dependencies and injections in a TypeScript-built rest web service without relying heavily on inversify for my domain classes, in line with the dependency inversion principle. Here's an overview of the project structure:
core/ (domain classes)
expressjs/ (web service context)
inversify/ (where injection magic for domain classes ideally occurs)
other-modules/ (concrete interface implementations using 3rd party technologies)
Here's how my classes are currently structured:
interface DomainInterface {
foo(): void;
}
interface DomainService {
bar();
}
class ConcreteClass implements DomainInterface {
constructor(colaborator: DomainService) { }
foo() {
this.colaborator.bar();
...
}
}
I aim to inject all dependencies through inversify without having to modify each domain class to make them injectable via @injectable decorator.
One approach I considered was creating a class within inversify module that contains @injectable dependencies, which each domain class could inherit from if needing injection. For example:
@injectable()
class InverisfyConcreteClass extends ConcreteClass {
constructor(@inject(DomainService) colaborator: DomainService) {
super(colaborator);
}
}
However, this would require many new classes due to the numerous domain classes present.
Another idea was to build a 'Context' class holding references to all classes, binding them to a container and retrieving when necessary:
class InversifyInjectionContext {
container: Container;
bind() {
// somehow bind all instances
}
concreteClass() {
return container.get<ConcreteClass>();
}
concreteDomainService() {
return container.get<AnyConcreteDomainService>();
}
}
The challenge now is generating instances and registering them correctly in the inversify container for future retrieval within the application.
What would be the optimal strategy to address this issue?