服务定位器（Service Locator）¶

Service Locator的数据结构¶

从上面的代码中，可以看到Service Locator维护了两个数组， $_components 和 $_definitions 。这两个数组均是以服务或组件的ID为键的数组。

其中， $_components 用于缓存存Service Locator中的组件或服务的实例。 Service Locator 为其提供了getter和setter。使其成为一个可读写的属性。 $_definitions 用于保存这些组件或服务的定义。这个定义可以是：

• 配置数组。在向Service Locator索要服务或组件时，这个数组会被用于创建服务或组件的实例。 与DI容器的要求类似，当定义是配置数组时，要求配置数组必须要有 class 元素，表示要创建的是什么类。不然你让Yii调用哪个构造函数？
• PHP callable。每当向Service Locator索要实例时，这个PHP callable都会被调用，其返回值，就是所要的对象。 对于这个PHP callable有一定的形式要求，一是它要返回一个服务或组件的实例。 二是它不接受任何的参数。 至于具体原因，后面会讲到。
• 对象。这个更直接，每当你索要某个特定实例时，直接把这个对象给你就是了。
• 类名。即，使得 is_callable($definition, true) 为真的定义。

从 yii\di\ServiceLocator::set() 的代码:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public function set($id, $definition)
{
    // 当定义为 null 时，表示要从Service Locator中删除一个服务或组件
    if ($definition === null) {
        unset($this->_components[$id], $this->_definitions[$id]);
        return;
    }

    // 确保服务或组件ID的唯一性
    unset($this->_components[$id]);

    // 定义如果是个对象或PHP callable，或类名，直接作为定义保存
    // 留意这里 is_callable的第二个参数为true，所以，类名也可以。
    if (is_object($definition) || is_callable($definition, true)) {
        // 定义的过程，只是写入了 $_definitions 数组
        $this->_definitions[$id] = $definition;

    // 定义如果是个数组，要确保数组中具有 class 元素
    } elseif (is_array($definition)) {
        if (isset($definition['class'])) {
            // 定义的过程，只是写入了 $_definitions 数组
            $this->_definitions[$id] = $definition;
        } else {
            throw new InvalidConfigException(
"The configuration for the \"$id\" component must contain a \"class\" element.");
        }

    // 这也不是，那也不是，那么就抛出异常吧
    } else {
        throw new InvalidConfigException(
            "Unexpected configuration type for the \"$id\" component: "
            . gettype($definition));
    }
}

服务或组件的ID在Service Locator中是唯一的，用于区别彼此。在任何情况下，Service Locator中同一ID只有一个实例、一个定义。也就是说，Service Locator中，所有的服务和组件，只保存一个单例。 这也是正常的逻辑，既然称为服务定位器，你只要给定一个ID，它必然返回一个确定的实例。这一点跟DI容器是一样的。

Service Locator 中ID仅起标识作用，可以是任意字符串，但通常用服务或组件名称来表示。 如，以 db 来表示数据库连接，以 cache 来表示缓存组件等。

至于批量注册的 yii\di\ServiceLocator::setCompoents() 只不过是简单地遍历数组，循环调用 set() 而已。 就算我不把代码贴出来，像你这么聪明的，一下子就可以自己写出来了。

向Service Locator注册服务或组件，其实就是向 $_definitions 数组写入信息而已。

访问Service Locator中的服务¶

Service Locator重载了 __get() 使得可以像访问类的属性一样访问已经实例化好的服务和组件。 下面是重载的 __get() 方法:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

public function __get($name)
{
    // has() 方法就是判断 $_definitions 数组中是否已经保存了服务或组件的定义
    // 请留意，这个时候服务或组件仅是完成定义，不一定已经实例化
    if ($this->has($name)) {

        // get() 方法用于返回服务或组件的实例
        return $this->get($name);

    // 未定义的服务或组件，那么视为正常的属性、行为，
    // 调用 yii\base\Component::__get()
    } else {
        return parent::__get($name);
    }
}

在注册好了服务或组件定义之后，就可以像访问属性一样访问这些服务（组件）。 前提是已经完成注册，不要求已经实例化。 访问这些服务或属性，被转换成了调用 yii\di\ServiceLocator::get() 来获取实例。 下面是使用这种形式访问服务或组件的例子:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// 创建一个Service Locator
$serviceLocator = new yii\di\ServiceLocator;

// 注册一个 cache 服务
$serviceLocator->set('cache', [
    'class' => 'yii\cache\MemCache',
    'servers' => [
        ... ...
    ],
]);

// 使用访问属性的方法访问这个 cache 服务
$serviceLocator->cache->flushValues();

// 上面的方法等效于下面这个
$serviceLocator->get('cache')->flushValues();

在Service Locator中，并未重载 __set() 。所以，Service Locator中的服务和组件看起来就好像只读属性一样。 要向Service Locator中“写”入服务和组件，没有 setter 可以使用，需要调用 yii\di\ServiceLocator::set() 对服务和组件进行注册。

DI容器的引入¶

我们知道，每个Yii应用都有一个入口脚本 index.php 。在其中，有一行不怎么显眼:

require(__DIR__ . '/../../vendor/yiisoft/yii2/Yii.php');

这一行看着普通，也就是引入一个 Yii.php 的文件。但是，让我们来看看这个 Yii.php

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<?php

require(__DIR__ . '/BaseYii.php');

class Yii extends \yii\BaseYii
{
}

spl_autoload_register(['Yii', 'autoload'], true, true);
Yii::$classMap = include(__DIR__ . '/classes.php');

// 重点看这里。创建一个DI 容器，并由 Yii::$container 引用
Yii::$container = new yii\di\Container;

Yii 是一个工具类，继承自 yii\BaseYii 。 但这里对父类的代码没有任何重载，意味之父类和子类在功能上其实是相同的。 但是，Yii提供了让你修改默认功能的机会。 就是自己写一个 Yii 类，来扩展、重载Yii默认的、由 yii\BaseYii 提供的特性和功能。 尽管实际使用中，我们还从来没有需要改写过这个类，主要是因为没有必要在这里写代码，可以通过别的方式实现。 但Yii确实提供了这么一个可能。这个在实践中不常用，有这么个印象就足够了。

这里重点看最后一句代码，创建了一个DI容器，并由 Yii::$container 引用。 也就是说， Yii 类维护了一个DI容器，这是DI容器开始介入整个应用的标志。 同时，这也意味着，在Yii应用中，我们可以随时使用 Yii::$container 来访问DI容器。 一般情况下，如无必须的理由，不要自己创建DI容器，使用 Yii::$container 完全足够。

Application的本质¶

再看看入口脚本 index.php 的最后两行:

$application = new yii\web\Application($config);
$application->run();

创建了一个 yii\web\Application 实例，并调用其 run() 方法。 那么，这个 yii\web\Application 是何方神圣？ 首先， yii\web\Application 继承自 yii\base\Application ，这从 yii\web\Application 的代码可以看出来

class Application extends \yii\base\Application
{
    ... ...
}

而 yii\base\Application 又继承自 yii\base\Module ，说明所有的Application都是Module

abstract class Application extends Module
{
    ... ...
}

那么 yii\base\Module 又继承自哪个类呢？不知道你猜到没，他继承自 yii\di\ServiceLocator

class Module extends ServiceLocator
{
    ... ...
}

所有的Module都是服务定位器Service Locator，因此，所有的Application也都是Service Locator。

同时，在Application的构造函数中， yii\base\Application::__construct()

1
2
3
4
5

public function __construct($config = [])
{
    Yii::$app = $this;
    ... ...
}

第一行代码就把Application当前的实例，赋值给 Yii::$app 了。 这意味着Yii应用创建之后，可以随时通过 Yii::$app 来访问应用自身，也就是访问Service Locator。

至此，DI容器有了，Service Locator也出现了。那么Yii是如何摆布这两者的呢？这两者又是如何千里姻缘一线牵的呢？

实例创建方法¶

Service Locator和DI容器的亲密关系就隐藏在 yii\di\ServiceLocator::get() 获取实例时， 调用的 Yii::createObject() 中。 前面我们说到这个 Yii 继承自 yii\BaseYii ，因此这个函数实际上是 BaseYii::createObject() ， 其代码如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// static::$container就是上面说的引用了DI容器的静态变量

public static function createObject($type, array $params = [])
{
    // 字符串，代表一个类名、接口名、别名。
    if (is_string($type)) {
        return static::$container->get($type, $params);

    // 是个数组，代表配置数组，必须含有 class 元素。
    } elseif (is_array($type) && isset($type['class'])) {
        $class = $type['class'];
        unset($type['class']);

        // 调用DI容器的get() 来获取、创建实例
        return static::$container->get($class, $params, $type);

    // 是个PHP callable则调用其返回一个具体实例。
    } elseif (is_callable($type, true)) {

        // 是个PHP callable，那就调用它，并将其返回值作为服务或组件的实例返回
        return call_user_func($type, $params);

    // 是个数组但没有 class 元素，抛出异常
    } elseif (is_array($type)) {
        throw new InvalidConfigException(
        'Object configuration must be an array containing a "class" element.');

    // 其他情况，抛出异常
    } else {
        throw new InvalidConfigException(
            "Unsupported configuration type: " . gettype($type));
    }
}

这个 createObject() 提供了一个向DI容器获取实例的接口， 对于不同的定义，除了PHP callable外， createObject() 都是调用了DI容器的 yii\di\Container::get() ， 来获取实例的。 Yii::createObject() 就是Service Locator和DI容器亲密关系的证明， 也是Service Locator构建于DI容器之上的证明。而Yii中所有的Module， 包括Application都是Service Locator，因此，它们也都构建在DI容器之上。

同时，在Yii框架代码中，只要创建实例，就是调用 Yii::createObject() 这个方法来实现。 可以说，Yii中所有的实例（除了Application，DI容器自身等入口脚本中实例化的），都是通过DI容器来获取的。

同时，我们不难发现， Yii 的基类 yii\BaseYii ，所有的成员变量和方法都是静态的， 其中的DI容器是个静态成员变量 $container 。 因此，DI容器就形成了最常见形式的单例模式，在内存中仅有一份，所有的Service Locator （Module和Application）都共用这个DI容器。 就就节省了大量的内存空间和反复构造实例的时间。

更为重要的是，DI容器的单例化，使得Yii不同的模块共用组件成为可能。 可以想像，由于共用了DI容器，容器里面的内容也是共享的。因此，你可以在A模块中改变某个组件的状态，而B模块中可以了解到这一状态变化。 但是，如果不采用单例模式，而是每个模块（Module或Application）维护一个自己的DI容器， 要实现这一点难度会大得多。

所以，这种共享DI容器的设计，是必然的，合理的。

另外，前面我们讲到，当Service Locator中服务或组件的定义是一个PHP callable时，对其形式有一定要求。 一是返回一个实例，二是不接收任何参数。 这在 Yii::createObject() 中也可以看出来。

由于 Yii::createObject() 为 yii\di\ServiceLocator::get() 所调用，且没有提供第二参数， 因此，当使用 Service Locator获取实例时， Yii::createObject() 的 $params 参数为空。 因此，使用 call_user_func($type, $params) 调用这个PHP callable时， 这个PHP callable是接收不到任何参数的。