事实上，你可以在没有IoC容器的情况下测试node.js，因为JavaScript是一种真正动态的编程语言，你可以在运行时修改几乎所有东西。

考虑以下几点:

import UserRepository from "./dal/user_repository";

class UserController {
    constructor() {
        this._repository = new UserRepository();
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

因此，您可以在运行时覆盖组件之间的耦合。我认为我们应该以解耦JavaScript模块为目标。

实现真正解耦的唯一方法是删除对UserRepository的引用:

class UserController {
    constructor(userRepository) {
        this._repository = userRepository;
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

这意味着你需要在其他地方进行对象合成:

import UserRepository from "./dal/user_repository";
import UserController from "./dal/user_controller";

export default new UserController(new UserRepository());

我喜欢将对象组合委托给IoC容器的想法。您可以在文章《JavaScript中依赖倒置的当前状态》中了解更多关于此思想的内容。这篇文章试图揭穿一些“JavaScript IoC容器神话”:

误解1:JavaScript中没有IoC容器的位置 误解2:我们不需要IoC容器，我们已经有模块加载器了! 误解3:依赖倒置===注入依赖

如果你也喜欢使用IoC容器的想法，你可以看看InversifyJS。最新版本(2.0.0)支持多种用例:

内核模块 内核的中间件 使用类、字符串或符号作为依赖标识符 常数值注入 类构造函数的注入 工厂注入 汽车工厂 提供程序的注入(异步工厂) 激活处理程序(用于注入代理) 多注射 标记绑定 自定义标记装饰器 指定绑定 上下文绑定 友好的异常(例如循环依赖)

你可以在InversifyJS上了解更多。

为了很好地测试应用程序，大多数时候最好使用反转控制工具在运行/测试时注入所需的对象。 所以最好不要在模块中直接使用require或import。而是调用DI容器来获取所需的对象。

如果你不想使用第三方库，你可以通过创建一个定制的DI容器来模仿IoC工具的行为。 在测试的时候，你可以模拟你的DI容器，并注入你的假模块用于测试。 下面是一个自定义DI容器的例子，这个版本的容器不支持接口。

myDependecy.js

const myDependecy = {};
export default myDependecy;

myDependecy.myTestFunction = () => {
  console.log("this is as test function.");
};

diContainer.js

import myDependecy from "./myDependecy.js";

const diContainer = {};
export default diContainer;

diContainer.myDependecy = myDependecy;

myModule.js

import diContainer from "./diContainer.js";

function myFunction() {
  diContainer.myDependecy.myTestFunction();
}

事实上，你可以在没有IoC容器的情况下测试node.js，因为JavaScript是一种真正动态的编程语言，你可以在运行时修改几乎所有东西。

考虑以下几点:

import UserRepository from "./dal/user_repository";

class UserController {
    constructor() {
        this._repository = new UserRepository();
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

因此，您可以在运行时覆盖组件之间的耦合。我认为我们应该以解耦JavaScript模块为目标。

实现真正解耦的唯一方法是删除对UserRepository的引用:

class UserController {
    constructor(userRepository) {
        this._repository = userRepository;
    }
    getUsers() {
        this._repository.getAll();
    }
}

export default UserController;

这意味着你需要在其他地方进行对象合成:

import UserRepository from "./dal/user_repository";
import UserController from "./dal/user_controller";

export default new UserController(new UserRepository());

我喜欢将对象组合委托给IoC容器的想法。您可以在文章《JavaScript中依赖倒置的当前状态》中了解更多关于此思想的内容。这篇文章试图揭穿一些“JavaScript IoC容器神话”:

误解1:JavaScript中没有IoC容器的位置 误解2:我们不需要IoC容器，我们已经有模块加载器了! 误解3:依赖倒置===注入依赖

如果你也喜欢使用IoC容器的想法，你可以看看InversifyJS。最新版本(2.0.0)支持多种用例:

内核模块 内核的中间件 使用类、字符串或符号作为依赖标识符 常数值注入 类构造函数的注入 工厂注入 汽车工厂 提供程序的注入(异步工厂) 激活处理程序(用于注入代理) 多注射 标记绑定 自定义标记装饰器 指定绑定 上下文绑定 友好的异常(例如循环依赖)

你可以在InversifyJS上了解更多。

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之间的选择取决于您的需求、系统复杂性和编程风格。

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

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

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

我一直很喜欢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