Angular.js - Javascript依赖注入

时间：2014-05-23 16:56:34

标签： javascript angularjs design-patterns dependency-injection

我读过DI和DI in Angular.js。

根据我的理解，Angular.js中的DI意味着Angular.js允许控制器，工厂，服务或其他人指定依赖项，而无需创建依赖项。

问题：

  1. 在某些时候，必须创建依赖项，使得创建依赖项的位置不是DIed，我该如何理解？

  2. 如果我有以下内容：

    var thing = function(dep){
  this.dep = dep || new depCreator();
}

    这是DIed吗？或取决于dep是否传递给函数？

  3. 从我看到，DI意味着允许设置一个依赖关系，在函数或对象中，最后，是否意味着将初始化/配置/数据与程序的其他部分分开（逻辑？虽然我们也可以有初始化逻辑）？：

    var dep1 = 'qwe';
var thing = function(dep){ this.dep = dep; }
var diedThing = new thing(dep1);

    这将允许在配置文件中设置dep1，例如。

  4. 如果实现DI的普通JavaScript是：

    var thing = function(dep){
  this.dep = dep;
}

    而不是

    var thing = function(){
  this.dep = new depCreator();
}

    这是对的吗？

    但是如果depCreator依赖于配置文件（或提取的配置），那会是DIed吗？

  5. 当我读到Angular.js有（？）DI时，认为这个DI意味着Angular.js为我创建并搜索依赖项是否正确？还有其他含义吗？

  6. 最后，如果DI是如此复杂，但意味着只是将配置与实现（或逻辑？）分开，为什么不把它称为单一责任原则，即方法做的方法做什么，配置做什么的配置，等等。

    7. 最后，DI对我来说是一个主观概念，在某些应用中你是如何想象和分担责任的，这是否接近正确？

    很抱歉这个问题很长。

1 个答案:

答案 0 :(得分：1)

  1. 创建依赖项的位置不依赖于它。它的唯一目的通常是创造＆＃34;事物＆＃34;并将其注册到DI子系统。没有什么奇怪或可疑的。

  2. 你为什么要这样做？如果您需要更大的灵活性，也许可以依赖于为您创建对象的服务。

  3. DI意味着依赖注入 - 正是这样，你不会创造你依赖自己的东西。相反，你要求它，瞧，它可供你使用。您不需要知道如何创建它，谁创建它等。

  4. 如果depCreator依赖于配置文件，那就没问题。它可以使用它们。在使用DI子系统注册dep之前，它几乎可以做任何事情。这就是你要做的，创建一个服务/工厂depCreator，它将注册dep并使其可用于你的应用程序的其他组件。

  5. 没有问号。 Angular 有一个DI子系统，它实际上是角度背后的核心思想之一。 Angular为您提供了许多随时可以注入的组件，其余的则必须自己创建和注册。

  6. 我不知道我是否会说DI很复杂。也许实施起来很棘手，我不知道，但是一旦你学会使用它，你就不会想要回去了。有角度的DI可能是我见过的最容易使用的。它很好，它有点透明。过了一段时间，你甚至没有注意到它在那里，而且所以很好。

    7. 我认为你的最后一句话是正确的。这是以我看待它的方式分离关注点。但是有很多很好的资源可以解释DI，所以我不在这里详述。像往常一样，我建议阅读ng-book以获得更具角度的细节。

相关问题
最新问题