使用$ injector.get（）在Angular中获取我的依赖项有什么缺点吗？

Question

My team wants to move to a style of dependency injection that is closer to the CommonJS/Node JS syntax for out Angular codebase:

var myDependency = require('myDependency');

I've started using $injector.get() directly inside at the top of my functions, so far with no obvious trouble. That means I've converted this:

angular.module('modD', ['modA', 'modB', 'modC'])
.service('serviceD', ['serviceA', 'serviceB', 'serviceC', function(serviceA, serviceB, serviceC) {
  //My code here
}])

Into:

angular.module('modD', ['modA', 'modB', 'modC'])
.service('serviceD', ['$injector', function($injector) {
  var serviceA = $injector.get('serviceA');
  var serviceB = $injector.get('serviceB');
  var serviceC = $injector.get('serviceC');

  //My code here
}]);

Is there something I'm missing. Does not declaring the required dependencies outside of the function definition cause any sort of performance issues?

Answer 1

Note: this answer has not been tested. After digging into the angular's code, I find this:

// in function createInjector
function provider(name, provider_) {
    ...
    if (isFunction(provider_) || isArray(provider_)) {
      provider_ = providerInjector.instantiate(provider_);
    }
    ...
    return providerCache[name + providerSuffix] = provider_;
}
...
function factory(name, factoryFn, enforce) {
    return provider(name, {
      $get: enforce !== false ? enforceReturnValue(name, factoryFn) : factoryFn
    });
}
function service(name, constructor) {
    return factory(name, ['$injector', function($injector) {
        return $injector.instantiate(constructor);
    }]);
}
...
// in function createInternalInjector
function invoke (...){
    ...
  for (i = 0, length = $inject.length; i < length; i++) {
    args.push(
      locals && locals.hasOwnProperty(key)
      ? locals[key]
      : getService(key, serviceName)
    );
  }
    ...
    return fn.apply(self, args);
}
function instantiate(...){
    ...
    var instance = Object.create((isArray(Type) ? Type[Type.length - 1] : Type).prototype || null);
    var returnedValue = invoke(Type, instance, locals, serviceName);
    return isObject(returnedValue) || isFunction(returnedValue) ? returnedValue : instance;

}
...
return {
    invoke: invoke,
    instantiate: instantiate,
    get: getService,
    annotate: createInjector.$$annotate,
    has: function(name) {
      return providerCache.hasOwnProperty(name + providerSuffix) || cache.hasOwnProperty(name);
    }
};

Its calls seems like:

• service invoked factory invoked instantiate
• factory invoked provider invoked instantiate

So I think your questions is equal to Is calling $injector.get() one by one has the same performance as calling $injector.instantiate() once?

As the code shows, instantiate invoked invoke which actually invoked getService for each services injected by you. And $injector.get is just binding to getService .

So the answer to my equal question is True .

And the answer to your question is No, their performance is very close .

Please correct me if I'm wrong, thank you!

Answer 2

There are no significant difference between both pieces of code in the case of a service. $injector.get(...) call doesn't provide any overhead. But it provides a significant amount of extra characters per dependency.

There is a difference when the same thing is done with injectables that have local dependencies - controllers and route/state resolvers.

When these dependencies

app.controller('SomeCtrl', function ($scope, service) { ... });

are replaced with $injector.get(...) , it will choke on $scope - it is local dependency. And with other dependencies being retrieved like that, controller loses its testability. The dependencies cannot be mocked with

$controller('SomeCtrl', { service: mockedService });

I personally don't see how $injector.get(...) may benefit the style of the project (and haven't seen a good style guide that would suggest it).

Node uses require function because it works for it, not because it is better or cooler. The alternative would be to pack each Node script into into AMD-like wrappers, which would be painful. Fortunately, we already have wrappers around Angular units!