在前端 javascript 應用程序中使用 DI 容器是否有意義

Question

我正在設計一個帶有 React 及其支持庫生態系統的應用程序。 這將是一個大型應用程序，具有許多服務和幫助程序模塊。 為了處理它們之間的依賴關系，使用 DI 容器是否有意義。

[更新]

請添加我們可用的缺失問題/解決方案，以准備包含/排除 DI 容器的良好指南

DI 容器試圖解決的幾個問題是

它可以輕松實現模塊的即插即用模塊構造函數的變化僅限於服務注冊

不使用 DI 容器，我有以下選項

我們使用工廠模塊（initaliser），它只是實例化，這將啟用插件，具有相同接口的不同模塊，並且不需要在消耗它的地方進行更改。

為了使其成為單例，服務模塊將導出它的實例，以便在包含它的任何地方引用相同的實例。

但是，將缺少的一件事是單個地方（注冊表），我們可以在其中找到不同模塊的所有依賴項。

Answer 1

視情況而定。 如果應用程序很小，那么可能沒有。 如果應用需求經常變化，你使用 SOLID 方法和 TS 那么它更有意義。

這就像問“開車上班好不好？”。 但是我們不知道您從家到工作地點有多遠，您有沒有停車的地方，您將在汽油上花多少錢以及公共交通票價是多少等等......

一般來說，DI 有助於使代碼對擴展開放，但對修改關閉（開放/關閉原則）。 創建高質量的代碼總是一個好主意。 可悲的是，從商業角度來看，簡單項目中的 DI 會浪費時間，並且會使前端人員的學習曲線更加陡峭。