据说99%的angular的初学者都会有一个疑问：factory和service到底有什么区别？什么情况该用factory，而什么情况又该用service呢？
比如这个Stackoverflow上的这个问题：Service vs Factory，又或者是这个问题：Service vs Provider vs Factory。
这些问题都有热心答主回答的很棒了，能够解释清它们共同点，区别以及典型用法。因此本文就换个角度，从最根本的角度来看看这两个概念在源代码层次上是如何实现的。
Factory
首先，我们来看看module上的factory方法，它是创建一个factory的入口方法：
factory: invokeLaterAndSetModuleName('$provide','factory')
// 对于factory而言就是调用: invokeLaterAndSetModuleName('$provide','factory')
function invokeLaterAndSetModuleName(provider,method) {
return function(recipeName,factoryFunction) {
// 在factory函数上设置module名称
if (factoryFunction && isFunction(factoryFunction)) factoryFunction.$$moduleName = name;
// 将factory的定义置入任务队列
invokeQueue.push([provider,method,arguments]);
return moduleInstance;
};
}
因此当我们使用该API创建一个factory时，该factory的”蓝图”可以表达成下面这个函数：
// 假设我们创建一个名为aFactory的factory实例：module.factory('aFactory',function(){})
// 其中的recipeName就是aFactory
function(recipeName,factoryFunction) {
if (factoryFunction && isFunction(factoryFunction)) factoryFunction.$$moduleName = name;
invokeQueue.push(['$provide','factory',arguments]);
return moduleInstance;
}
因此和前面讨论过的provider和constant一样，factory最终也是由$provide.factory方法生产制造出来的(provider对应$provide.provider，constant对应$provide.constant)：
function factory(name,factoryFn,enforce) {
return provider(name,{
$get: enforce !== false ? enforceReturnValue(name,factoryFn) : factoryFn
});
}
从上面这段代码就可以看出现端倪了。在factory函数的实现内部，它利用了provider实现其功能。如果对于provider有疑问可以先看看这篇文章 - 依赖注入 — Provider是个啥。
我们知道provider的目的就是定义依赖应该如何被生成。而定义这个任务的核心就是其内部的$get方法。而factory的目的也是为了定义一个依赖，从目的上而言它和provider的目的不谋而合。因此，factory函数在内部创建了一个符合provider契约的对象，该对象的$get方法实际上就是参数中的factoryFn，而这个factoryFn则是我们定义的。因此调用$get方法就是再调用factoryFn，返回的值也是我们在factoryFn中定义的返回值。
只不过factory函数的第三个参数对具体的$get方法有一点点影响，如果不将它显式地设置成false(必须是false，undefine，null这些都不算)，那么就会保证该factory必须是返回值的，否则会抛出异常：
function enforceReturnValue(name,factory) {
return function enforcedReturnValue() {
// 实例注入器完成调用
var result = instanceInjector.invoke(factory,this);
// 如果返回值为undefined，抛出异常
if (isUndefined(result)) {
throw $injectorMinErr('undef',"Provider '{0}' must return a value from $get factory method.",name);
}
return result;
};
}
由于我们平常使用factory很少关注第三个参数，因此事实上我们总是确保了factory必须要返回点东西作为其返回值。
分析到这里，factory的实现其实没什么新玩意，算是新瓶装旧酒吧，本质上还是利用了provider来完成其功能。值得注意的地方是，factory必须要返回一个值，由于factory是通过实例注入器来调用的，因此它的返回值最终会被保存到实例注入器的cache中，所以以后不管什么地方通过需要它，拿到的都是同一份实例，也就是说这个factory其实是一个单例对象，在整个angular应用中都只有一份。因此factory中保存的数据是全局唯一的，我们可以把它当作一个用于保存全局数据的地方。
Service
看完了factory的实现，我们再来看看service。service这个名字其实挺泛的，什么东西都可以叫做一个service，factory难道就不是一个service吗？下面是它相关的代码：
// Module API
service: invokeLaterAndSetModuleName('$provide','service')
和同样定义在Module API中的factory非常相似，只不过第二个参数从’factory’变成了’service’。这个service指向的函数如下所示：
// Injector内部的service函数
function service(name,constructor) {
return factory(name,['$injector',function($injector) {
return $injector.instantiate(constructor);
}]);
}
注意service函数的第二个参数名是constructor，也隐含着它和factory的不同。即我们传入的函数是会被当作一个构造函数来调用的，其内部的实现也证实了这一点：
// 调用的是注入器的instantiate方法，而非invoke方法
return $injector.instantiate(constructor);
另外一个非常非常有意思的地方是，service的内部利用了factory！它实际上还是创建了一个factory，只不过这个factory的任务就是实例化我们定义的constructor：
// 内部利用factory完成service的功能
return factory(name,function($injector) {
return $injector.instantiate(constructor);
}]);
在内部创建的factory中，使用基于数组的风格完成了注解的声明(如果不清楚注解是什么，可以先看这篇文章：依赖注入 — 注解的定义与实现)。它依赖于$injector服务，那么这个$injector是指的实例注入器呢，还是provider注入器呢？
首先我们知道service，factory这一类对象在需要被实例化的时候，实例化它们的请求都是通过实例注入器发起的。当实例注入器发现实例化一个service的时候，还需要首先处理掉它的依赖，也就是上述代码中出现的$injector时，就会首先去实例注入器自身的cache中寻找，发现没有名为”$injector“的对象后，就会去寻求provider注入器的帮助(关于这个流程的具体细节，可以参考依赖注入 — instance注入器以及provider注入器)，这个时候就会使用键值”$injectorProvider“去provider注入器中寻找，而恰好在创建注入器的时候就已经定义好这个对象了：
// providerSuffix就是"Provider"
// protoInstanceInjectorj就是实例注入器
providerCache['$injector' + providerSuffix] = { $get: valueFn(protoInstanceInjector) };
所以最终$injector对应的就是实例注入器，使用的是实例注入器来完成service构造函数的实例化。和factory的一点不同在于，service并不需要定义一个明确的返回值，因为注入器总是会将service的函数当作构造函数创建出一个新对象出来作为依赖。而factory则是自己声明返回的对象作为依赖。
简单总结
Factory和Service是我们经常用的两个API，它们都能够帮助我们定义依赖注入需要的对象。它们的共同点和不同点简单总结如下：
共同点
- 创建的对象都是单例对象。这一点是依赖注入机制确保的，因为一旦一个对象被创建完毕了，它总是会被保存到实例注入器的cache中，下次查找这个对象时总是能够从cache中找到它，因此就没有必要再次创建了。
- 在底层都创建了一个临时的provider。这一点体现在factory的实现中，而service又在内部依赖于factory。因此它们最终都依赖于这个临时的provider。
