《AngularJS深度剖析与最佳实践》一2.9 服务

简介:

本节书摘来自华章出版社《AngularJS深度剖析与最佳实践》一书中的第2章,第2.9节,作者 雪狼 破狼 彭洪伟,更多章节内容可以访问云栖社区“华章计算机”公众号查看

2.9 服务

如果你是一个后端程序员,那么对服务(Service)的概念一定不会陌生。在Angular中,服务的概念是一样的,差别只在于技术细节。
服务是对公共代码的抽象,比如,如果在多个控制器中都出现了相似的代码,那么把它们提取出来,封装成一个服务,你将更加遵循DRY原则(即:不要重复你自己),在可维护性等方面获得提升。
如同我们在第1章的tree服务中所看到的,由于服务剥离了和具体表现相关的部分,而聚焦于业务逻辑或交互逻辑,它更加容易被测试和复用。
但是,在工程实践中,我们引入服务的首要目的是为了优化代码结构,而不是复用。复用只是一项结果,不是目标。所以,当你发现你的代码中混杂了表现层逻辑和业务层逻辑的时候,你就要认真考虑抽取服务了—哪怕它还看不到复用价值。
如果你遵循着测试驱动开发的方式,那么当你觉得测试很难写的时候,回头审视下,看是否这里可以抽取出一个服务,转而对服务进行测试。
服务的概念通常是和依赖注入紧密相关的,Angular中也一样。如果你困惑于在JavaScript中是如何实现依赖注入的,请参见第3章“背后的原理”中的3.3节“依赖注入”。
由于依赖注入的要求,服务都是单例的,这样我们才能把它们到处注入,而不用手动管理它们的生命周期,并容许Angular实现“延迟初始化”等优化措施。
在Angular中,服务分成很多种类型:
常量(Constant):用于声明不会被修改的值。
变量(Value):用于声明会被修改的值。
服务(Service):没错,它跟服务这个大概念同名,原作者在“开发者指南”中把这种行为比喻为“把自己的孩子取名叫‘孩子’—一个会气疯老师的名字”。事实上,同名的原因是—它跟后端领域的“服务”实现方式最为相似:声明一个类,等待Angular把它new出来,然后保存这个实例,供它到处注入。
工厂(Factory):它跟上面这个“服务”不同,它不会被new出来,Angular会调用这个函数,获得返回值,然后保存这个返回值,供它到处注入。它被取名为“工厂”是因为:它本身不会被用于注入,我们使用的是它的产品。但是与现实中的工厂不同,它只产出一份产品,我们只是到处使用这个产品而已。
供应商(Provider):“工厂”只负责生产产品,它的规格是不受我们控制的,而“供应商”更加灵活,我们可以对规格进行配置,以便获得定制化的产品。
事实上,除了Constant外,所有这些类型的服务,背后都是通过Provider实现的,我们可以把它们看做让Provider更容易写的语法糖。一个明显的佐证是:当你使用一个未定义的服务时,Angular给你的错误提示是它对应的Provider未找到,比如我们使用一个未定义的服务:test,那么Angular给出的提示是:Unknown provider: testProvider <- test。
Constant比较特殊,我们稍后讲解,我们先来看其他几个。
Provider的声明方式如下:

angular.module('com.ngnice.app').provider('greeting', function() {
    var _name = 'world';
    this.setName = function(name) {
        _name = name;
    };
    this.$get = function(/*这里可以放依赖注入变量*/) {
        return 'Hello, ' + _name;
    };
});

使用时:

angular.module('com.ngnice.app').controller('SomeCtrl', function($scope, greeting) {
    // 这里greeting应该等于'Hello, world',怎么样,你猜对了吗?
    $scope.message = greeting;
});

对Provider进行配置时:

angular.module('com.ngnice.app').config(function(greetingProvider) {
    greetingProvider.setName('wolf');
});

容器的伪代码如下:

var instance = diContainer['greeting'];         // 先找是否已经有了一个实例
if (!angular.isUndefined(instance)) {
    return instance;                            // 如果已经有了一个实例,直接返回
}

var ProviderClass = angular.module('com.ngnice.app').lookup('greetingProvider'); // 在服务名后面自动加上Provider后缀是Angular遵循的一项约定
var provider = new ProviderClass();   // 把Provider实例化
provider.setName('wolf');
instance = provider.$get();           // 调用$get,并传入依赖注入参数
diContainer['greeting'] = instance;   // 把调用结果存下来
return instance;

事实上,如果不需要对name参数进行配置,声明代码可以简化为:
angular.module('com.ngnice.app').value('greeting', 'Hello, world');
这也就是需要这么多语法糖的原因。
下面给出其他语法糖的等价形式:

2.9.1 服务

angular.module('com.ngnice.app').service('greeting', function() {
    this.sayHello = function(name) {
        return 'Hello, ' + name;
    };
});

等价于:

angular.module('com.ngnice.app').provider('greeting', function() {
    this.$get = function() {
        var Greeting = function() {
            this.sayHello = function(name) {
                return 'Hello, ' + name;
            };
        };
        return new Greeting();
    };
};

使用时:

angular.module('com.ngnice.app').controller('SomeCtrl', function($scope, greeting) {
    $scope.message = greeting.sayHello('world');
});

2.9.2 工厂

angular.module('com.ngnice.app').factory('greeting', function() {
    return 'Hello, world';
});

等价于:

angular.module('com.ngnice.app').provider('greeting', function() {
    this.$get = function() {
        var greeting = function() {
            return 'Hello, world';
        };
        return greeting();
    }
});

使用时:

angular.module('com.ngnice.app').controller('SomeCtrl', function($scope, greeting) {
    $scope.message = greeting;
});

在Angular源码中,它们的实现是这样的:

function factory(name, factoryFn) { return provider(name, { $get: factoryFn }); }

function service(name, constructor) {
    return factory(name, ['$injector', function($injector) {
        return $injector.instantiate(constructor);
    }]);
}

function value(name, val) { return factory(name, valueFn(val)); }

Angular提供了这么多种形式的服务,那么我们在工程实践中该如何选择?我们可以遵循下列决策流程:
需要全局的可配置参数?用Provider。
是纯数据,没有行为?用Value。
只new一次,不用参数?用Service。
拿到类,我自己new出实例?用Factory。
拿到函数,我自己调用?用Factory。
但是,还有另一种更加敏捷的方式:
是纯数据时,先用Value;当发现需要添加行为时,改写为Service;或当发现需要通过计算给出结果时,改写为Factory;当发现需要进行全局配置时,改写为Provider。
最酷的是,这个过程对于使用者是透明的—它不需要因为实现代码的改动而更改原有代码。如上面Value和Factory的使用代码,仅仅从使用代码中我们区分不出它是Value还是Factory。
接下来,我们来看Constant。与其他Service不同,Constant不是Provider函数的语法糖。更重要的差别是,它的初始化时机非常早,可以在angular.module('com.ngnice.app').config函数中使用,而其他的服务是不能被注入到config函数中的。这也意味着,如果你需要在config中使用一个全局配置项,那么它就只能声明为常量,而不能声明为变量。
在官方的开发指南中,给出了一个完整的对比表,见表2-1。
image

下面给出解释:
可以依赖其他服务:由于Value和Constant的特殊声明形式,显然没有进行依赖注入的时机。
使用类型友好的注入:这条没有官方的解释,我的理解是—由于Factory可以根据程序逻辑返回不同的数据类型,所以我们无法推断其结果是什么类型,也就是对类型不够友好。Provider由于其灵活性比Factory更高,因此在类型友好性上和Factory是一样的。
在config阶段可用:只有Constant和Provider类型在config阶段可用,其他都是Provider实例化之后的结果,所以只有config阶段完成后才可用。
可用于创建函数/原生对象:由于Service是new出来的,所以其结果必然是类实例,也就无法直接返回一个可供调用的函数或数字等原生对象。
如果你确实需要对一个没有提供Provider的第三方服务进行配置,该怎么办呢?Angular提供了另一种机制:decorator。这个decorator和前面提到过的装饰器型指令没有关系,它是用来改变服务的行为的。
比如我们有一个第三方服务,名叫ui,它有一个prompt函数,我们不能改它源码,但需要让它每次弹出提问框时都在控制台输出一条记录,那么我们可以这样写:

angular.module('com.ngnice.app').config(function($provide) {
    // $delegate是ui的原始服务
    $provide.decorator('ui', function($delegate) {
        // 保存原始的prompt函数
        var originalPrompt = $delegate.prompt;
        // 用自己的prompt替换
        $delegate.prompt = function() {
            // 先执行原始的prompt函数
            originalPrompt.apply($delegate, arguments);
            // 再写一条控制台日志
            console.log('prompt');
        };
        // 返回原始服务的实例,但也可以返回一个全新的实例
        return $delegate;
    })
});

这种方式给你了超级灵活性,你可以改写包括Angular系统服务在内的任何服务—事实上,angular-mocks模块就是使用decorator来MOCK $httpBackend、$timeout等服务的。
不过,如果你大幅修改了原始服务的逻辑,那么,这可能会给自己和维护者挖坑。俗话说,“不作死就不会死”。如果让我来总结decorator的使用原则,那就是—慎用、慎用、慎用,如果确实想用,请务必遵循“Liskov代换”原则,并写好单元测试。特别是,如果你想修改系统服务的工作逻辑,建议先多看几遍文档,确保你正确理解了它的每一个细节!

相关文章
|
前端开发 JavaScript
《AngularJS深度剖析与最佳实践》推荐序
《AngularJS深度剖析与最佳实践》推荐序
|
安全 前端开发 测试技术
《AngularJS深度剖析与最佳实践》一导读
现在,软件不但运行在PC上,还要运行在智能手机上,运行在各种Pad上,屏幕分辨率更是多到让研发和测试工程师发怵的地步。
1425 0