【问题标题】:Using the $injector instance directly vs. obtaining dependencies as parameters直接使用 $injector 实例与获取依赖项作为参数
【发布时间】:2015-05-25 12:44:12
【问题描述】:

在 Angular 中,直接从 $injector 实例而不是作为参数获取依赖项是否被认为是一种好习惯?

我遇到的问题是我的控制器开始有很多依赖项,所以而不是:

myApp.controller(['$scope', 'Dep1', 'Dep2', 'Dep3', function($scope, Dep1, Dep2, Dep3) {
    ...
}]);

我愿意:

myApp.controller(['$scope', '$injector', function($scope, $injector) {
    var Dep1 = $injector.get('Dep1');
    var Dep2 = $injector.get('Dep2');
    var Dep3 = $injector.get('Dep3');
}]);

我发现它在功能方面是相同的,但参数上的混乱要少得多。我想这会让我的组件不太容易测试,对吧?

你怎么看?

【问题讨论】:

  • 如果你总是要在多个控制器中使用 Dep1,Dep2,Dep3。您可以创建一个将这些导出为属性的服务,然后仅依赖于该服务。
  • 测试是一个因素。真正的问题是大量的依赖通常表明你的控制器做得太多了。什么是“大”取决于具体情况。

标签: javascript angularjs


【解决方案1】:

这取决于您编写代码的方式以及对您而言是否容易并让您灵活地编写代码。我总是以这种方式编写控制器,希望它会有所帮助:}

var appCtrl = function($scope, others){...}
app.controller('appCtrl',['$scope', 'others', appCtrl]);

【讨论】:

    【解决方案2】:

    根据我的意见并阅读以下帖子后:

    Post 1

    Post 2

    Angular's documentation on DI (Dependency Injection)

    您为了最小化长依赖列表的第二种方法被认为是服务定位器反模式。 见-Service locator AntiPattern

    使用服务定位器反模式是不好的,因为它会使您作为维护开发人员的生活变得更糟,因为您需要使用大量的脑力来掌握所做的每一个更改的含义。使用 $injector 会混淆资源的实际依赖关系(在本例中为控制器)并破坏可维护性。

    另外,根据angular's documentation,最好的方式是:

    使用内联数组注解(首选)

    如果您的控制器最终使用了如此多的依赖项,则可能您做错了什么,也许您破坏了Single responsibility principle。考虑:

    1. 将更多逻辑委托给注入的服务
    2. 分成不同的控制器,因此每个控制器只有(大约)一项职责

    【讨论】:

      猜你喜欢
      • 2015-12-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-06-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多