我是在回答我自己的DI模块上的一个问题时发现这个问题的，这个问题是为什么有人需要一个DI系统来进行NodeJS编程。

答案显然倾向于这篇文章中给出的答案:这要看情况。这两种方法都有折衷之处，阅读这个问题的答案可以让你更好地了解它们。

所以，这个问题的真正答案应该是，在某些情况下，你会使用依赖注入系统，在其他情况下则不会。

也就是说，作为开发人员，您希望的是不要在各种应用程序中重复使用您的服务。

这意味着我们应该编写一些可以在依赖注入系统中使用但不绑定到依赖注入库的服务。对我来说，这意味着我们应该像这样编写服务:

module.exports = initDBService;

// Tells any DI lib what it expects to find in it context object
// The $inject prop is the de facto standard for DI imo 
initDBService.$inject = ['ENV'];

// Note the context object, imo, a DI tool should bring
// services in a single context object
function initDBService({ ENV }) {
/// actual service code
}

这样你的服务就可以工作了，不管你是和谁一起使用 没有依赖注入工具。

我还写了一个模块来完成这一点，它被称为rewire。只需使用npm安装rewire，然后:

var rewire = require("rewire"),
    myModule = rewire("./path/to/myModule.js"); // exactly like require()

// Your module will now export a special setter and getter for private variables.
myModule.__set__("myPrivateVar", 123);
myModule.__get__("myPrivateVar"); // = 123


// This allows you to mock almost everything within the module e.g. the fs-module.
// Just pass the variable name as first parameter and your mock as second.
myModule.__set__("fs", {
    readFile: function (path, encoding, cb) {
        cb(null, "Success!");
    }
});
myModule.readSomethingFromFileSystem(function (err, data) {
    console.log(data); // = Success!
});

我受到Nathan MacInnes注射剂的启发，但使用了不同的方法。我不使用vm来评估测试模块，事实上我使用节点自己的要求。这样，您的模块的行为与使用require()完全相同(除了您的修改)。此外，完全支持调试。

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

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依赖注入 包文档在这里

我希望它能帮到你。

我开发了一个库，用一种简单的方式处理依赖注入，减少了样板代码。每个模块由唯一的名称和控制器函数定义。控制器的参数反映了模块的依赖关系。

阅读更多关于KlarkJS的内容

简单的例子:

KlarkModule(module, 'myModuleName1', function($nodeModule1, myModuleName2) {
    return {
        log: function() { console.log('Hello from module myModuleName1') }
    };
});

myModuleName1是模块的名称。 $nodeModule1是node_module的一个外部库。名称解析为node-module1。前缀$表示它是一个外部模块。 myModuleName2是一个内部模块的名称。 控制器的返回值来自其他内部模块，当它们定义参数myModuleName1时。

对于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()

我制作《电解质》就是为了这个目的。其他依赖注入解决方案对我来说太有侵入性了，而混淆全局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依赖项，并将实例作为参数注入导出函数。

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

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