在前端javascript应用程序中使用DI容器有意义吗？

Question

我正在设计一个带有React及其支持库生态系统的应用程序。它将是一个大型应用程序，包含大量的服务和辅助模块。要处理它们之间的依赖关系，使用DI容器是否有意义。

更新

请添加缺少的问题/解决方案，以编写包含/排除DI容器的良好指南。

DI容器试图解决的几个问题是

它使模块易于即插即用，模块构造函数的更改仅限于服务注册。

不使用DI容器，我有以下选项

我们使用的工厂模块(Initaliser)，它只是实例化，这将启用插头，不同的模块具有相同的接口，不需要改变它的消费地点。

为了使它成为单例，服务模块将导出它的实例，因此在包含它的任何地方都会引用相同的实例。

但是，有一件事将被遗漏，那就是我们可以找到不同模块的所有依赖项的单一位置(注册表)。

Answer 1

取决于案子的情况。如果应用程序是小的，那么可能没有。如果应用程序需求经常发生变化，那么使用可靠的方法和TS就更有意义了。

这就像问“开车去上班好吗？”但是我们不知道你从家里到工作还有多远，你在哪里停车，你打算花多少钱在汽油上，而公共交通的票价是多少等等。

一般说来，DI有助于使代码为扩展打开，但为修改而关闭(开放/关闭原则)。创建高质量的代码总是个好主意。可悲的是，从商业的角度来看，DI在简单的项目中是浪费时间的，它将使前端人的学习曲线更加陡峭。