Angular.js - Javascript依赖注入

Question

我读过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是如此复杂，但意味着只是将配置与实现（或逻辑？）分开，为什么不把它称为单一责任原则，即方法做的方法做什么，配置做什么的配置，等等。

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

很抱歉这个问题很长。

Answer 1

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

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

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

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

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

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

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