我认为我们仍然需要Nodejs中的依赖注入，因为它放松了服务之间的依赖关系，使应用程序更加清晰。

受Spring Framework的启发，我也实现了自己的模块来支持Nodejs中的依赖注入。我的模块还能够检测代码更改并自动重新加载服务，而无需重新启动应用程序。

访问我的项目:Buncha - IoC容器

谢谢你！

我制作《电解质》就是为了这个目的。其他依赖注入解决方案对我来说太有侵入性了，而混淆全局require是我特别不满的地方。

电解质包含模块，特别是那些导出“设置”功能的模块，就像你在Connect/Express中间件中看到的那样。本质上，这些类型的模块只是它们所返回的对象的工厂。

例如，创建数据库连接的模块:

var mysql = require('mysql');

exports = module.exports = function(settings) {
  var connection = mysql.createConnection({
    host: settings.dbHost,
    port: settings.dbPort
  });

  connection.connect(function(err) {
    if (err) { throw err; }
  });

  return connection;
}

exports['@singleton'] = true;
exports['@require'] = [ 'settings' ];

您在底部看到的是注释，这是一个额外的元数据，电解质使用它来实例化和注入依赖关系，自动将应用程序的组件连接在一起。

创建一个数据库连接。

var db = electrolyte.create('database');

电解质传递遍历@require'd依赖项，并将实例作为参数注入导出函数。

关键是这是微创的。这个模块是完全可用的，独立于电解质本身。这意味着您的单元测试可以只测试被测试的模块，传入模拟对象，而不需要额外的依赖关系来重新连接内部。

当运行完整的应用程序时，电解质在模块间级别介入，将东西连接在一起，而不需要全局变量、单例或过多的管道。

这取决于应用程序的设计。显然，你可以做一个类似java的注入，在那里创建一个类的对象，并将依赖项传递给构造函数，就像这样。

function Cache(store) {
   this._store = store;
}

var cache = new Cache(mysqlStore);

如果你不是在javascript中做OOP，你可以做一个init函数来设置一切。

然而，还有另一种方法可以采用，这种方法在基于事件的系统(如node.js)中更为常见。如果您可以将应用程序建模为仅(大多数时候)对事件进行操作，那么您所需要做的就是设置所有内容(我通常通过调用init函数来完成)并从存根发出事件。这使得测试相当容易和易读。

require()和最近的ES模块(import)是管理Node.js中的依赖关系的方法，当然它是直观和有效的，但它也有其局限性。

我的建议是看一看目前Node.js中可用的依赖注入容器，了解它们的优缺点。其中一些是:

awilix injection-js bottlejs inversify node-dependency-injection

举几个例子。

现在真正的问题是，与简单的require()或import相比，使用Node.js DI容器可以实现什么?

优点:

better testability: modules accepts their dependencies as input Inversion of Control: decide how to wire your modules without touching the main code of your application. a customizable algorithm for resolving modules: dependencies have "virtual" identifiers, usually they are not bound to a path on the filesystem. Better extensibility: enabled by IoC and "virtual" identifiers. Other fancy stuff possible: Async initialization Module lifecycle management Extensibility of the DI container itself Can easily implement higher level abstractions (e.g. AOP)

缺点:

与Node.js的“体验”不同:使用DI绝对感觉你偏离了Node的思维方式。 依赖项与其实现之间的关系并不总是明确的。依赖项可能在运行时被解析，并受到各种参数的影响。代码变得更加难以理解和调试 启动时间较慢 大多数DI容器不能很好地与Browserify和Webpack等模块捆绑器一起使用。

与软件开发相关的任何事情一样，在DI或require()/import之间的选择取决于您的需求、系统复杂性和编程风格。

I worked with .Net, PHP and Java for long time so I wanted to have a convenient Dependency Injection in NodeJS too. People said the built-in DI in NodeJS is enough as we can get it with Module. But it didn't satisfy me well. I wanted to keep a Module no more than a Class. Additionally, I wanted the DI to have a full support for Module life cycle management (singleton module, transient module etc.) but with Node module, I had to write manual code very often. Lastly, I wanted to make Unit Test easier. That's why I created a Dependency Injection for myself.

如果您正在寻找DI，请尝试一下。可以在这里找到:https://github.com/robo-creative/nodejs-robo-container。它有完整的文档。并对依赖注入中常见的问题进行了分析，并提出了面向对象的解决方法。希望能有所帮助。

它应该像这样灵活和简单:

var MyClass1 = function () {}
var MyClass2 = function (myService1) {
    // myService1.should.be.instanceof(MyClass1); 
}


container.register('myService1', MyClass1);
container.register('myService2', MyClass2, ['myService1']);

我写过一篇关于node.js中的依赖注入的文章。

管理你的服务-node.js依赖注入 包文档在这里

我希望它能帮到你。