在前端使用DI容器是否有意义javascript app

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

[更新]

请添加缺失的问题/解决方案，我们都可以准备一个很好的指引，包含/排除DI容器

即DI容器试图解决几个问题

它能够轻松插头和模块在模块的构造变化的发挥被限制在服务注册

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

我们使用工厂模块（initaliser）刚刚实例化，这将使塞，不同的模块有相同的接口，并不会需要它消耗的变化。

为了让单身，服务模块将出口它的实例，使无论它包含相同的实例被称为。

有一两件事，将会虽然缺少的是一个地方（注册表），在这里我们可以找到不同的模块的所有依赖。

来源

2016-05-05 bmhaskar

这可能会因为基于意见而关闭。这就是说，作为需要在工作中使用Angular 1.x的人，我会说这不值得 - 它只是阻碍了任何事情。在我看来，你最好使用像Webpack或Browserify这样的好模块捆绑器。 –

而不是意见，我认为真正的使用，像你这样的开发者体验，以及在实现它之后取得的最终结果应该试图回答它。 – bmhaskar

是的，对于它的价值，我没有提出这个问题，因为我不能100％确定它是否属于这个类别。我认为最能说明我感觉如何的答案是FailedUnitTest的一个 - DI是一个问题的解决方案，而不是每个应用程序都应该使用的东西。这就是为什么我个人更喜欢React;像这样的设计模式是选择性的，而不是强加在每个项目上。 –

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

这就像问“车是好开车去上班？”。但是，我们不知道是多远，你得到从你家的工作，你有没有地方停车，有多少你打算在天然气支出VS什么是公共交通车票费用等..

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

来源

2016-05-05 14:32:07 PolishDeveloper

是的，我们计划使用TS，并且要求将会改变。辅助程序库，组件，缩减程序的应用程序大小很大。根据您的建议，您有资格获得DI。 – bmhaskar

DI trully给你的是一个“更换零部件的简单方法”，就像在汽车里一样 - 你可以很容易地更换轮胎/收音机。即使更换引擎也是可能的 - 唯一的要求是互换组件必须实现相同的接口。例如，如果更换无线电，连接套接字必须相同。然后，如果您正确实施所有服务，则可以轻松更改应用程序组件（例如将对讲集成从对讲机更改为桌面。COM） - 易意味着你只需要创建一个新的服务，并注入它，您不必更改所有类的代码，以使其工作 – PolishDeveloper

例如Angular1.x使用DI和它的作品真的很好 – PolishDeveloper

在前端使用DI容器是否有意义javascript app

回答

相关问题