对于ES6，我开发了这个容器 https://github.com/zazoomauro/node-dependency-injection

import {ContainerBuilder} from 'node-dependency-injection'

let container = new ContainerBuilder()
container.register('mailer', 'Mailer')

然后，您可以设置，例如，在集装箱中的运输选择:

import {ContainerBuilder} from 'node-dependency-injection'

let container = new ContainerBuilder()
container
  .register('mailer', 'Mailer')
  .addArgument('sendmail')

这个类现在灵活得多，因为您已经将传输的选择从实现中分离出来，并将其放入容器中。

现在邮件服务已经在容器中，您可以将其作为其他类的依赖项注入。如果你有一个这样的newsletter ttermanager类:

class NewsletterManager {
    construct (mailer, fs) {
        this._mailer = mailer
        this._fs = fs
    }
}

export default NewsletterManager

在定义newsletter tter_manager服务时，邮件服务还不存在。使用Reference类告诉容器在初始化通讯管理器时注入mailer服务:

import {ContainerBuilder, Reference, PackageReference} from 'node-dependency-injection'
import Mailer from './Mailer'
import NewsletterManager from './NewsletterManager'

let container = new ContainerBuilder()

container
  .register('mailer', Mailer)
  .addArgument('sendmail')

container
  .register('newsletter_manager', NewsletterManager)
  .addArgument(new Reference('mailer'))
  .addArgument(new PackageReference('fs-extra'))

你也可以用Yaml、Json或JS文件等配置文件来设置容器

由于各种原因，可以编译服务容器。这些原因包括检查任何潜在的问题，如循环引用和使容器更高效。

container.compile()

我一直很喜欢IoC的简单理念——“你不需要了解任何环境，需要的时候有人会叫你。”

但是我看到的所有IoC实现都完全相反——它们用更多的东西使代码变得混乱。所以，我创建了我自己的IoC，就像我想要的那样-它保持隐藏和不可见的90%的时间。

它用于MonoJS web框架http://monojs.org

我说的是简单的事情，比如共享一个数据库连接对象 但我还没有找到一个让我满意的解决办法。

它是这样做的——在配置中注册组件一次。

app.register 'db', -> 
  require('mongodb').connect config.dbPath

可以在任何地方使用

app.db.findSomething()

你可以在https://github.com/sinizinairina/mono/blob/master/mono.coffee这里看到完整的组件定义代码(包括DB Connection和其他组件)

这是你必须告诉IoC该做什么的唯一地方，之后所有这些组件都将自动创建和连接，你不再需要在应用程序中看到IoC特定的代码。

国际奥委会本身https://github.com/alexeypetrushin/miconjs

我最近创建了一个名为circuitbox的库，它允许你在node.js中使用依赖注入。与我见过的许多基于依赖项查找的库相比，它实现了真正的依赖项注入。Circuitbox还支持异步创建和初始化例程。下面是一个例子:

假设下面的代码位于名为consoleMessagePrinter.js的文件中

'use strict';

// Our console message printer
// deps is injected by circuitbox with the dependencies
function ConsoleMessagePrinter(deps) {
  return {
    print: function () {
      console.log(deps.messageSource.message());
    }
  };
}

module.exports = ConsoleMessagePrinter;

假设main.js文件中包含以下内容

'use strict';

// our simple message source
// deps is injected by circuitbox with the dependencies
var simpleMessageSource = function (deps) {
  return {
    message: function () {
      return deps.message;
    }
  };
};

// require circuitbox
var circuitbox = require('../lib');

// create a circuitbox
circuitbox.create({
  modules: [
    function (registry) {
      // the message to be used
      registry.for('message').use('This is the message');

      // define the message source
      registry.for('messageSource').use(simpleMessageSource)
        .dependsOn('message');

      // define the message printer - does a module.require internally
      registry.for('messagePrinter').requires('./consoleMessagePrinter')
        .dependsOn('messageSource');
    }
  ]
}).done(function (cbx) {

  // get the message printer and print a message
  cbx.get('messagePrinter').done(function (printer) {
    printer.print();
  }, function (err) {
    console.log('Could not recieve a printer');
    return;
  });

}, function (err) {
  console.log('Could not create circuitbox');
});

Circuitbox允许您定义组件并将它们的依赖项声明为模块。一旦初始化，它允许您检索组件。Circuitbox自动注入目标组件所需的所有组件，并将其提供给您使用。

该项目处于alpha版本。欢迎您的评论、想法和反馈。

希望能有所帮助!

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

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

var cache = new Cache(mysqlStore);

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

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

我认为其他的文章在使用DI的论证方面做得很好。对我来说，原因是

注入依赖项而不知道它们的路径。这意味着如果您更改磁盘上的模块位置或将其与另一个模块交换，则不需要触及依赖于该模块的每个文件。 它使模拟依赖关系以进行测试变得更加容易，而不用痛苦地重写全局require函数，而且不会出现任何问题。 它可以帮助您将应用程序组织为松散耦合的模块。

但是我很难找到一个我和我的团队可以轻松采用的依赖注入框架。所以我最近基于这些特性构建了一个名为deppie的框架

可以在几分钟内学会的最小API 不需要额外的代码/配置/注释 一对一直接映射需要的模块 可以部分地使用现有代码吗

Node.js和其他平台一样需要DI。如果您正在构建一些大的东西，DI将使您更容易模拟代码的依赖关系并彻底测试代码。

例如，数据库层模块不应该只在业务代码模块中使用，因为在单元测试这些业务代码模块时，dao将加载并连接到数据库。

一种解决方案是将依赖项作为模块参数传递:

module.exports = function (dep1, dep2) {
// private methods

   return {
    // public methods
       test: function(){...}
   }
}

通过这种方式，依赖关系可以轻松自然地模拟，你可以专注于测试你的代码，而不需要使用任何棘手的第三方库。

还有其他的解决方案(百老汇，建筑师等)可以帮助你解决这个问题。尽管他们可能做的比你想要的多，或者使用更多的杂物。