事实上，你可以在没有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上了解更多。

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

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

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

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

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

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

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

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

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

var cache = new Cache(mysqlStore);

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

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

我知道这个帖子在这一点上是相当老的，但我想我会在这个问题上发表我的想法。TL;DR是由于JavaScript的无类型、动态特性，您实际上可以在不依赖依赖注入(DI)模式或使用DI框架的情况下做很多事情。然而，随着应用程序变得越来越大、越来越复杂，DI无疑可以帮助提高代码的可维护性。

c# DI

要理解JavaScript中为什么不需要依赖注入，看看强类型语言(如c#)是很有帮助的。(向那些不懂c#的人道歉，但它应该很容易理解。)假设我们有一个应用程序描述了一辆汽车和它的喇叭。你将定义两个类:

class Horn
{
    public void Honk()
    {
        Console.WriteLine("beep!");
    }
}

class Car
{
    private Horn horn;

    public Car()
    {
        this.horn = new Horn();
    }

    public void HonkHorn()
    {
        this.horn.Honk();
    }
}

class Program
{
    static void Main()
    {
        var car = new Car();
        car.HonkHorn();
    }
}

以这种方式编写代码几乎没有什么问题。

The Car class is tightly coupled to the particular implementation of the horn in the Horn class. If we want to change the type of horn used by the car, we have to modify the Car class even though its usage of the horn doesn't change. This also makes testing difficult because we can't test the Car class in isolation from its dependency, the Horn class. The Car class is responsible for the lifecycle of the Horn class. In a simple example like this it's not a big issue, but in real applications dependencies will have dependencies, which will have dependencies, etc. The Car class would need to be responsible for creating the entire tree of its dependencies. This is not only complicated and repetitive, but it violates the "single responsibility" of the class. It should focus on being a car, not creating instances. There is no way to reuse the same dependency instances. Again, this isn't important in this toy application, but consider a database connection. You would typically have a single instance that is shared across your application.

现在，让我们重构它以使用依赖注入模式。

interface IHorn
{
    void Honk();
}

class Horn : IHorn
{
    public void Honk()
    {
        Console.WriteLine("beep!");
    }
}

class Car
{
    private IHorn horn;

    public Car(IHorn horn)
    {
        this.horn = horn;
    }

    public void HonkHorn()
    {
        this.horn.Honk();
    }
}

class Program
{
    static void Main()
    {
        var horn = new Horn();
        var car = new Car(horn);
        car.HonkHorn();
    }
}

我们已经做了两件关键的事情。首先，我们介绍了一个由Horn类实现的接口。这让我们可以将Car类编码到接口，而不是特定的实现。现在代码可以接受任何实现IHorn的东西。其次，我们从Car中取出喇叭实例化，并将其传入。这解决了上述问题，并将其留给应用程序的主要功能来管理特定的实例及其生命周期。

这意味着我们可以在不接触car类的情况下为car引入一种新的喇叭类型:

class FrenchHorn : IHorn
{
    public void Honk()
    {
        Console.WriteLine("le beep!");
    }
}

主程序可以直接注入一个FrenchHorn类的实例。这也极大地简化了测试。您可以创建一个MockHorn类注入到Car构造函数中，以确保您只测试Car类。

上面的例子展示了手动依赖注入。典型的依赖注入是通过框架完成的(例如c#世界中的Unity或Ninject)。这些框架将通过遍历依赖关系图并根据需要创建实例来为您完成所有依赖关系连接。

标准的Node.js方式

现在让我们看看Node.js中的相同示例。我们可能会把代码分成3个模块:

// horn.js
module.exports = {
    honk: function () {
        console.log("beep!");
    }
};

// car.js
var horn = require("./horn");
module.exports = {
    honkHorn: function () {
        horn.honk();
    }
};

// index.js
var car = require("./car");
car.honkHorn();

因为JavaScript是无类型的，所以我们没有以前那样的紧密耦合。不需要接口(也不存在接口)，因为car模块只会尝试在horn模块导出的任何内容上调用honk方法。

此外，因为Node需要缓存所有内容，所以模块本质上是存储在容器中的单例。对horn模块执行require的任何其他模块都将获得完全相同的实例。这使得共享单例对象(如数据库连接)非常容易。

现在仍然存在一个问题，即car模块负责获取它自己的依赖喇叭。如果希望汽车使用不同的喇叭模块，则必须更改car模块中的require语句。这不是一件很常见的事情，但它确实会导致测试问题。

通常人们处理测试问题的方法是使用proxyquire。由于JavaScript的动态特性，proxyquire会拦截需要的调用，并返回您提供的存根/mock。

var proxyquire = require('proxyquire');
var hornStub = {
    honk: function () {
        console.log("test beep!");
    }
};

var car = proxyquire('./car', { './horn': hornStub });

// Now make test assertions on car...

这对于大多数应用程序来说已经足够了。如果它适用于你的应用，那就采用它。然而，根据我的经验，随着应用程序变得越来越大、越来越复杂，维护这样的代码变得越来越困难。

JavaScript中的DI

Node.js非常灵活。如果你对上面的方法不满意，你可以使用依赖注入模式来编写你的模块。在此模式中，每个模块导出一个工厂函数(或类构造函数)。

// horn.js
module.exports = function () {
    return {
        honk: function () {
            console.log("beep!");
        }
    };
};

// car.js
module.exports = function (horn) {
    return {
        honkHorn: function () {
            horn.honk();
        }
    };
};

// index.js
var horn = require("./horn")();
var car = require("./car")(horn);
car.honkHorn();

这与前面的c#方法非常相似，因为index.js模块负责实例生命周期和连接。单元测试非常简单，因为您只需将mock /存根传递给函数。同样，如果这对您的应用程序来说足够好，那么就使用它。

Bolus DI框架

与c#不同的是，没有现成的标准依赖注入框架来帮助你管理依赖项。npm注册表中有许多框架，但没有一个被广泛采用。这些选项中的许多已经在其他答案中被引用。

我对所有的选项都不是特别满意，所以我写了自己的bolus。Bolus的设计是为了与上面的DI风格编写的代码一起工作，并试图非常DRY和非常简单。使用上面完全相同的car.js和horn.js模块，你可以用bolus重写index.js模块:

// index.js
var Injector = require("bolus");
var injector = new Injector();
injector.registerPath("**/*.js");

var car = injector.resolve("car");
car.honkHorn();

基本思想是创建一个注入器。你在注入器中注册了所有的模块。然后你只需解决你所需要的。Bolus将遍历依赖关系图，并根据需要创建和注入依赖关系。在这样一个简单的例子中，您不会节省太多，但是在具有复杂依赖树的大型应用程序中，节省的时间是巨大的。

Bolus supports a bunch of nifty features like optional dependencies and test globals, but there are two key benefits I've seen relative to the standard Node.js approach. First, if you have a lot of similar applications, you can create a private npm module for your base that creates an injector and registers useful objects on it. Then your specific apps can add, override, and resolve as needed much like how AngularJS's injector works. Second, you can use bolus to manage various contexts of dependencies. For example, you could use middleware to create a child injector per request, register the user id, session id, logger, etc. on the injector along with any modules depending on those. Then resolve what you need to serve requests. This gives you instances of your modules per request and prevents having to pass the logger, etc. along to every module function call.

TypeDI是这里提到的最可爱的，看看TypeDI中的代码

import "reflect-metadata";
import {Service, Container} from "typedi";

@Service()
class SomeClass {

    someMethod() {
    }

}

let someClass = Container.get(SomeClass);
someClass.someMethod();

看看这段代码:

import {Container, Service, Inject} from "typedi";

// somewhere in your global app parameters
Container.set("authorization-token", "RVT9rVjSVN");

@Service()
class UserRepository {

    @Inject("authorization-token")
    authorizationToken: string;

}

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

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

我希望它能帮到你。