javascript - 为什么 Angular JS 中的依赖注入(inject)比手动管理依赖更好？

Question

具体说到 DI 功能，我不是 Angular 的粉丝，我不太相信 Angular 使您的代码更易于测试，甚至更容易编写更可测试的代码。

在我看来，您最终会得到很多额外的抽象层，实际上是间接的，只是为了支持一些“魔法”——也就是说，使函数参数名称自动实例化。如果没有这个功能 - 即:神奇地获取 $http 或 $car 的实例，或者调用你的函数时的任何东西 - 它似乎并没有提供那么多。

在使这些调用显式化的过程中，需要付出多少额外的努力，需要多少间接和魔法？你最终得到的是一个“全局”(从你的应用程序的 Angular 来看)命名空间......所以不手动做这些事情真的只有一点点方便。

来自文档:

myModule.factory('greeter', function($window) {
  return {
    greet: function(text) {
      $window.alert(text);
    }
  };
});
function MyController($scope, greeter) {
  $scope.sayHello = function() {
    greeter.greet('Hello World');
  };
}

这里的神奇之处在于“greeter”是根据参数名称​​自动注入(inject)的，对吧？我假设 $scope 是一样的，尽管据我了解，所有 Controller 都应该将 $scope 作为第一个参数，因此情况可能并非如此。

一个非魔法的例子:

function MyController() {
  var scope = myApp.get('scope');
  var greeter = myApp.get('greeter');
  scope.sayHello = function() {
    greeter.greet('Hello World');
  }
}

如您所见，我只是添加了一个“.get()”方法来获取您的依赖项。我知道 Angular 完全可以做到这一点——但这不是我读过的文档建议的主要情况。

非魔法测试:

function myControllerTest() {
  var scope = {};
  var greeter = { greet: function() {} };
  myApp.set('scope', scope);
  myApp.set('greeter', greeter);
  // ... run an actual test on MyController here
}

我并没有真正用 Angular 做过什么重要的事情，但是随着年龄的增长和脾气暴躁，我发现我越来越不喜欢魔术了。我非常高兴添加(比方说)多 20% 的代码行以避免间接级别，这意味着我无法轻松地单步执行我的代码，无论框架或语言如何。

有人可以举一个合理的例子来说明 Angular 对 DI 的作用，而这对于一些基本约定的手工操作来说并不是没有问题的吗？我错过了“魔术”的好处，只是为了避免明确定义您的依赖关系吗？

Answer 1

依赖注入(inject)是经典 OOP 文献中所谓“隔离”的一种奇特的新方式。这意味着对象不应该知道外部世界。这是封装的补充原则，即外部世界不应该知道对象的内部工作原理。实际上，这意味着如果您使用依赖注入(inject)，则不会使用全局变量。依赖注入(inject)不是一个框架，它是一个设计原则。 Angulars DI 框架只是为了让它更容易。正如您正确指出的那样，使用 DI 通常会引入间接。这就是你付出的代价。如果你不同意，那完全没问题。在许多情况下，DI 肯定会使您的代码更难理解。不过，它会产生更具可组合性和模块化的软件。

在您的“非魔法”版本中，您基本上引入了一个“服务定位器”。这导致对 myApp 的依赖。从 DI 的 Angular 来看，这种依赖是最糟糕的一种，因为它是隐藏的、间接的和全局的。 “隐藏”意味着它不是函数参数。只有阅读代码本身才能看到它。间接意味着，您真正关心的是 greeter，但您依赖的是 myApp。全局应该是显而易见的。有很多关于为什么全局变量通常不好的争论，但对于测试来说，问题在于你的测试彼此共享状态。您不能以这种方式孤立地运行测试。这可能会导致“测试不稳定”，这意味着某些测试有时会失败，有时不会，这取决于另一个测试。