Question

我正在试图弄清楚依赖注入在Node中的位置。即使我知道它在Java中是如何工作的，我也似乎无法理解它，我一直在阅读无数的博客。

net imo上的示例是 trivial 。他们并没有真正展示为什么需要DI。我更喜欢一个复杂的例子。

我查看了以下框架：

https://github.com/young-steveo/bottlejs

http://inversify.io/

现在，Node使用模块模式。当我进行导入时，它会收到一个单例，因为这是节点的作用，它会缓存模块，除非工厂模式用于返回一个新实例（返回新的MyThing（））。

现在，依赖注入主要功能是将所有内容分离。

当人们这么说时，我认为目标是...要从模块顶部删除所有导入。

我今天的写作：

'use strict';

// node modules
import os from 'os';
...8 more modules here
import fs from 'fs';
// npm modules
import express from 'express';
...8 more modules here
import _ from 'lodash';
// local modules
import moduleOne from './moduleOne';
...8 more modules here
import moduleTen from './moduleTen';

//...rest of my code

进口30次是一件痛苦的事情。在多个文件中使用相同的30是一个更大的痛苦。

我正在阅读https://blog.risingstack.com/fundamental-node-js-design-patterns/，我查看了依赖注入区域。在示例1中，依赖性被传递，很好。那么 30 呢？我认为这不是好的做法吗？

如何构建具有如此多依赖关系的应用程序？并使它适合单元测试和嘲笑？

Answer 1

实现Ioc模式，因为依赖注入在您的项目中始终是一个非常好的选择，这允许您对软件进行分离和粒化，使其更灵活，更不僵硬。使用节点js模块模式非常难以在代码中实现抽象，这在良好的体系结构中始终是必需的，这样做，使您的代码满足来自SOLID的D [Dependency Inversion]并更容易实现SOI。

如果您想查看DI的用例，请参阅此存储库的自述文件也是节点Jems DI的DI库，它会使模块中的长导入列表无效，并且不会让您100％依赖它通过放置元数据或强迫您在依赖于DI库的模块中编写额外代码或者有时不需要业务逻辑，总是在DI库和实例激活之间放置一些抽象。

具有许多导入的节点中的依赖注入

1 个答案: