我正在使用React及其支持库生态系统设计应用程序。它将成为一个大型应用程序，具有大量服务和帮助程序模块。要处理它们之间的依赖关系，使用DI容器是否有意义。
[更新]
请添加我们可用的缺失问题/解决方案，以准备好包含/排除DI容器的指南
DI容器试图解决的问题很少
它可以轻松实现模块的即插即用 模块构造函数的更改仅限于服务注册
不使用DI容器，我有以下选项
我们使用刚刚实例化的工厂模块（初始化），这将启用插件，具有相同接口的不同模块，并且不需要在消耗的地方进行更改。
要使其成为单例，服务模块将导出它的实例，以便在包含它的任何地方引用相同的实例。
有一件事将会遗漏的是单个地方（注册表），在那里我们可以找到不同模块的所有依赖项。
答案 0 :(得分：1)
取决于案件。如果应用程序很小，那么可能没有。如果应用程序要求经常更改，您使用SOLID方法和TS然后它会更有意义。
这就像询问＆＃34;汽车是否适合开车上班？＆＃34;。但我们不知道你从家到工作有多远，你有停车地点，你花多少钱购买汽油和公共交通票价等等...... / p>
一般情况下，DI有助于为扩展打开代码，但关闭修改（打开/关闭原则）。创建高质量的代码始终是个好主意。遗憾的是，从简单的项目中，从业务角度看，DI将浪费时间，并且会为前端人员提供更陡峭的学习曲线。