JavaScript模块化和依赖注入之间的区别

模块化是指将代码分解为单独的、独立的"包"。
依赖关系注入是指不对其他模块的引用进行硬编码。

作为一个实际的例子，你可以编写不使用依赖注入的模块：

import { Foo } from 'foo';
export function Bar() {
    return Foo.baz();
}

这里有两个模块，但此模块导入一个特定的其他硬编码模块。

使用依赖注入编写的相同模块：

export function Bar(foo) {
    return foo.baz();
}

然后其他人可以将其用作：

import { Foo } from 'foo';
import { Bar } from 'bar';
Bar(Foo());

在调用时注入Foo依赖项，而不是对依赖项进行硬编码。

您可以参考这篇文章：

模块是实现某些功能和 是使用特定技术编写的。没有开箱即用 JavaScript语言中的模块化方案。即将到来的 ECMAScript 6 规范倾向于通过引入 JavaScript语言本身的模块概念。这就是未来。

和 JavaScript 中的依赖注入

目标

假设我们有两个模块。第一个是服务 发出 Ajax 请求，第二个是路由器。

var service = function() {
    return { name: 'Service' };
}
var router = function() {
    return { name: 'Router' };
}

我们还有另一个需要这些模块的功能。

var doSomething = function(other) {
    var s = service();
    var r = router();
};

为了使事情更有趣一点的功能 需要再接受一个参数。当然，我们可以使用上面的代码， 但这并不灵活。如果我们想使用ServiceXML或 服务JSON。或者，如果我们想模拟一些模块怎么办 测试目的。我们不能只编辑函数的主体。这 我们都想出的第一件事是将依赖项作为 函数的参数。即：

var doSomething = function(service, router, other) {
    var s = service();
    var r = router();
};

通过这样做，我们正在传递模块的确切实现 我们想要的。然而，这带来了一个新问题。想象一下，如果我们有 在我们的代码中做一些事情。如果我们需要第三个会发生什么 屬地。我们无法编辑函数的所有调用。所以，我们需要一个 将为我们做到这一点的仪器。这就是依赖注入器 正在尝试解决。让我们写下我们想要的几个目标 实现：

• 我们应该能够注册依赖项
• 注入器应该接受一个函数，并应该返回一个以某种方式获得所需资源的函数
• 我们不应该写很多，我们需要简短而漂亮的语法
• 注入器应保留传递函数的范围
• 传递的函数应该能够接受自定义参数，而不仅仅是描述的依赖项

一个不错的清单不是吗。让我们潜入。