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;

}

我最近检查了这个线程，原因和OP差不多——我遇到的大多数库都临时重写了require语句。我用这种方法取得了不同程度的成功，所以我最终使用了下面的方法。

在一个快速应用程序的上下文中-我将app.js包装在bootstrap.js文件中:

var path = require('path');
var myapp = require('./app.js');

var loader = require('./server/services/loader.js');

// give the loader the root directory
// and an object mapping module names 
// to paths relative to that root
loader.init(path.normalize(__dirname), require('./server/config/loader.js')); 

myapp.start();

传递给加载器的对象映射是这样的:

// live loader config
module.exports = {
    'dataBaseService': '/lib/dataBaseService.js'
}

// test loader config
module.exports = {
    'dataBaseService': '/mocks/dataBaseService.js'
    'otherService' : {other: 'service'} // takes objects too...
};

然后，不要直接调用require…

var myDatabaseService = loader.load('dataBaseService');

如果加载器中没有别名，那么它将默认为常规require。 这样做有两个好处:我可以交换类的任何版本，并且消除了这种需要 在整个应用程序中使用相对路径名(因此如果我需要下面的自定义库 或以上的当前文件，我不需要遍历，并要求将缓存模块针对相同的关键)。它还允许我在应用程序的任何位置指定模拟，而不是在立即的测试套件中。

为了方便起见，我刚刚发布了一个小的npm模块:

https://npmjs.org/package/nodejs-simple-loader

我知道这个帖子在这一点上是相当老的，但我想我会在这个问题上发表我的想法。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.

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

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

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

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

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。它有完整的文档。并对依赖注入中常见的问题进行了分析，并提出了面向对象的解决方法。希望能有所帮助。

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