javascript - Angular.js - Javascript 依赖注入(inject)

Question

我读到了DI和 DI in Angular.js .

据我了解，Angular.js 中的 DI 意味着 Angular.js 允许 Controller 、工厂、服务或其他对象指定依赖项，而无需创建依赖项。

问题:

1. 在某些时候必须创建依赖项，从而使创建依赖项的位置不被删除，我如何理解这一点？

2. 如果我有:

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

   这是死了吗？或者取决于 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. 创建依赖的地方不依赖它。它的唯一目的通常是创建“事物”并将其注册到 DI 子系统。这没有什么奇怪或可疑的。

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

3. DI 意味着依赖注入(inject) - 确切地说，您不会创建您自己依赖的东西。相反，你要求它，瞧，它就提供给你了。您不需要知道如何创建它、谁创建了它等等。

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

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

6. 我不知道是否会说 DI 很复杂。也许实现起来很棘手，我不知道，但一旦你学会使用它，你就不会想回去了。 Angular 中的 DI 可能是我见过的最容易使用的。太好了，有点透明。一段时间后，您甚至没有注意到它的存在，而且它运行得很好。

我认为你最后的话是正确的。在我看来，这是一种关注点分离的方式。但是有很多很多很好的资源可以解释 DI，所以我不会在这里详细说明。一如既往，我建议阅读 ng-book 以获取更多 Angular 具体细节。