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

Does it make sense to use DI container in front end javascript app

本文关键字：DI 有意义前端 javascript 应用程序更新时间：2023-09-26

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

[更新]

请添加我们可用的遗漏问题/解决方案，以准备一份包括/排除DI容器的良好指南

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

它实现了模块的简单即插即用模块构造函数的更改仅限于服务注册

在不使用DI容器的情况下，我有以下选项

我们使用工厂模块（initaliser），它只是实例化，这将启用插件，具有相同接口的不同模块，并且不需要更改它的使用位置。

为了使它成为单例，服务模块将导出它的实例，以便在包含它的任何地方引用同一个实例。

不过，有一点是缺失的，那就是我们可以在单一位置（注册表）找到不同模块的所有依赖项。

取决于具体情况。如果应用程序很小，那么可能不会。如果应用程序需求经常变化，您使用SOLID方法和TS，那么它更有意义。

这就像在问"开车去上班好吗？"。但我们不知道你从家到工作有多远，你有停车的地方吗，你在汽油上要花多少钱，公共交通票价是多少等等…

一般来说，DI有助于使代码对扩展开放，但对修改关闭（打开/关闭原则）。创建高质量的代码总是个好主意。遗憾的是，从商业人士的角度来看，DI在简单的项目中会浪费时间，而且会使前端人员的学习曲线变得更陡峭。