服务services

在11.0版中，我们引入了服务的概念。主要的想法是给子组件一种受控制的方式来访问它们的环境，这种方式允许框架进行足够的控制，并且是可测试的。
服务系统围绕三个理念进行组织：services、service providers和widget。它的工作方式是小部件触发（使用trigger_up）事件，这些事件冒泡到服务提供者，服务提供者将要求服务执行任务，然后可能返回一个答案。

服务service

服务是AbstractService类的实例。它基本上只有一个名称和一些方法。它的工作是执行一些工作，通常是一些依赖于环境的工作。
例如，我们有Ajax服务（任务是执行RPC）、本地存储（与浏览器本地存储交互）和许多其他服务。
以下是有关如何实现Ajax服务的简化示例：

1
2
3
4
5
6
7
8

var AbstractService = require('web.AbstractService');

var AjaxService = AbstractService.extend({
    name: 'ajax',
    rpc: function (...) {
        return ...;
    },
});

这个服务被叫做‘ajax’而且定义了一个方法，rpc.

服务提供者Service Provider

为了使服务正常工作，有必要让一个服务提供者准备好分派定制事件。在后端（Web客户端），这是由主Web客户端实例完成的。请注意，服务提供程序的代码来自ServiceProviderMin。

部件widget

小部件是请求服务的部分。为了做到这一点，它只需触发一个事件调用服务（通常通过使用helper函数调用）。此事件将冒泡并将意图传达给系统的其余部分。
在实践中，有些函数被频繁地调用，以至于我们有一些助手函数使它们更容易使用。例如，_rpc方法是帮助生成rpc的助手。

1
2
3
4
5
6
7
8

var SomeWidget = Widget.extend({
    _getActivityModelViewID: function (model) {
        return this._rpc({
            model: model,
            method: 'get_activity_view_id'
        });
    },
});

警告
如果一个小部件被销毁，它将从主组件树中分离出来，并且没有父组件。在这种情况下，事件不会冒泡，这意味着工作不会完成。这通常正是我们从一个被破坏的小部件中想要的。