依赖注入和依赖注入容器¶

构造函数注入¶

构造函数注入通过构造函数的形参，为类内部的抽象单元提供实例化。 具体的构造函数调用代码，由外部代码决定。具体例子如下:

 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
35
36
37

// 这是构造函数注入的例子
class Comment extend yii\db\ActiveRecord
{
    // 用于引用发送邮件的库
    private $_eMailSender;

    // 构造函数注入
    public function __construct($emailSender)
    {
        ...
        $this->_eMailSender = $emailSender;
        ...
    }

    // 当有新的评价，即 save() 方法被调用之后中，会触发以下方法
    public function afterInsert()
    {
        ...
        //
        $this->_eMailSender->send(...);
        ...
    }
}

// 实例化两种不同的邮件服务，当然，他们都实现了EmailSenderInterface
sender1 = new GmailSender();
sender2 = new MyEmailSender();

// 用构造函数将GmailSender注入
$comment1 = new Comment(sender1);
// 使用Gmail发送邮件
$comment1.save();

// 用构造函数将MyEmailSender注入
$comment2 = new Comment(sender2);
// 使用MyEmailSender发送邮件
$comment2.save();

上面的代码对比原来的代码，解决了Comment类对于GmailSender等具体类的依赖，通过构造函数，将相应的实现了 EmailSenderInterface接口的类实例传入Comment类中，使得Comment类可以适用于不同的邮件服务。 从此以后，无论要使用何何种邮件服务，只需写出新的EmailSenderInterface实现即可， Comment类的代码不再需要作任何更改，多爽的一件事，扩展起来、测试起来都省心省力。

属性注入¶

与构造函数注入类似，属性注入通过setter或public成员变量，将所依赖的单元注入到类内部。 具体的属性写入，由外部代码决定。具体例子如下:

 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
35
36
37

// 这是属性注入的例子
class Comment extend yii\db\ActiveRecord
{
    // 用于引用发送邮件的库
    private $_eMailSender;

    // 定义了一个 setter()
    public function setEmailSender($value)
    {
        $this->_eMailSender = $value;
    }

    // 当有新的评价，即 save() 方法被调用之后中，会触发以下方法
    public function afterInsert()
    {
        ...
        //
        $this->_eMailSender->send(...);
        ...
    }
}

// 实例化两种不同的邮件服务，当然，他们都实现了EmailSenderInterface
sender1 = new GmailSender();
sender2 = new MyEmailSender();

$comment1 = new Comment;
// 使用属性注入
$comment1->eMailSender = sender1;
// 使用Gmail发送邮件
$comment1.save();

$comment2 = new Comment;
// 使用属性注入
$comment2->eMailSender = sender2;
// 使用MyEmailSender发送邮件
$comment2.save();

上面的Comment如果将 private $_eMailSender 改成 public $eMailSender 并删除 setter函数， 也是可以达到同样的效果的。

与构造函数注入类似，属性注入也是将Comment类所依赖的EmailSenderInterface的实例化过程放在Comment类以外。 这就是依赖注入的本质所在。为什么称为注入？从外面把东西打进去，就是注入。什么是外，什么是内？ 要解除依赖的类内部就是内，实例化所依赖单元的地方就是外。

DI容器中的内容¶

 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

class Instance
{
    // 仅有的属性，用于保存类名、接口名或者别名
    public $id;

    // 构造函数，仅将传入的ID赋值给 $id 属性
    protected function __construct($id)
    {
    }

    // 静态方法创建一个Instance实例
    public static function of($id)
    {
        return new static($id);
    }

    // 静态方法，用于将引用解析成实际的对象，并确保这个对象的类型
    public static function ensure($reference, $type = null, $container = null)
    {
    }

    // 获取这个实例所引用的实际对象，事实上它调用的是
    // yii\di\Container::get()来获取实际对象
    public function get($container = null)
    {
    }
}

DI容器的数据结构¶

在DI容器中，维护了5个数组，这是DI容器功能实现的基础:

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

// 用于保存单例Singleton对象，以对象类型为键 private $_singletons = []; // 用于保存依赖的定义，以对象类型为键 private $_definitions = []; // 用于保存构造函数的参数，以对象类型为键 private $_params = []; // 用于缓存ReflectionClass对象，以类名或接口名为键 private $_reflections = []; // 用于缓存依赖信息，以类名或接口名为键 private $_dependencies = [];

DI容器的5个数组内容和作用如 DI容器5个数组示意图 所示。

DI容器5个数组示意图

注册依赖¶

使用DI容器，首先要告诉容器，类型及类型之间的依赖关系，声明一这关系的过程称为注册依赖。 使用 yii\di\Container::set() 和 yii\di\Container::setSinglton() 可以注册依赖。 DI容器是怎么管理依赖的呢？要先看看 yii\di\Container::set() 和 yii\Container::setSinglton()

 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

public function set($class, $definition = [], array $params = [])
{
    // 规范化 $definition 并写入 $_definitions[$class]
    $this->_definitions[$class] = $this->normalizeDefinition($class,
        $definition);

    // 将构造函数参数写入 $_params[$class]
    $this->_params[$class] = $params;

    // 删除$_singletons[$class]
    unset($this->_singletons[$class]);
    return $this;
}

public function setSingleton($class, $definition = [], array $params = [])
{
    // 规范化 $definition 并写入 $_definitions[$class]
    $this->_definitions[$class] = $this->normalizeDefinition($class,
        $definition);

    // 将构造函数参数写入 $_params[$class]
    $this->_params[$class] = $params;

    // 将$_singleton[$class]置为null，表示还未实例化
    $this->_singletons[$class] = null;
    return $this;
}

这两个函数功能类似没有太大区别，只是 set() 用于在每次请求时构造新的实例返回， 而 setSingleton() 只维护一个单例，每次请求时都返回同一对象。

表现在数据结构上，就是 set() 在注册依赖时，会把使用 setSingleton() 注册的依赖删除。 否则，在解析依赖时，你让Yii究竟是依赖续弦还是原配？因此，在DI容器中，依赖关系的定义是唯一的。 后定义的同名依赖，会覆盖前面定义好的依赖。

从形参来看，这两个函数的 $class 参数接受一个类名、接口名或一个别名，作为依赖的名称。 $definition 表示依赖的定义，可以是一个类名、配置数组或一个PHP callable。

这两个函数，本质上只是将依赖的有关信息写入到容器的相应数组中去。 在 set() 和 setSingleton() 中，首先调用 yii\di\Container::normalizeDefinition() 对依赖的定义进行规范化处理，其代码如下:

 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

protected function normalizeDefinition($class, $definition)
 {
     // $definition 是空的转换成 ['class' => $class] 形式
     if (empty($definition)) {
         return ['class' => $class];

     // $definition 是字符串，转换成 ['class' => $definition] 形式
     } elseif (is_string($definition)) {
         return ['class' => $definition];

     // $definition 是PHP callable 或对象，则直接将其作为依赖的定义
     } elseif (is_callable($definition, true) || is_object($definition)) {
         return $definition;

     // $definition 是数组则确保该数组定义了 class 元素
     } elseif (is_array($definition)) {
         if (!isset($definition['class'])) {
             if (strpos($class, '\\') !== false) {
                 $definition['class'] = $class;
             } else {
                 throw new InvalidConfigException(
                     "A class definition requires a \"class\" member.");
             }
         }
         return $definition;
     // 这也不是，那也不是，那就抛出异常算了
     } else {
         throw new InvalidConfigException(
             "Unsupported definition type for \"$class\": "
             . gettype($definition));
     }
 }

规范化处理的流程如下：

• 如果 $definition 是空的，直接返回数组 ['class' => $class]
• 如果 $definition 是字符串，那么认为这个字符串就是所依赖的类名、接口名或别名， 那么直接返回数组 ['class' => $definition]
• 如果 $definition 是一个PHP callable，或是一个对象，那么直接返回该 $definition
• 如果 $definition 是一个数组，那么其应当是一个包含了元素 $definition['class'] 的配置数组。 如果该数组未定义 $definition['class'] 那么，将传入的 $class 作为该元素的值，最后返回该数组。
• 上一步中，如果 definition['class'] 未定义，而 $class 不是一个有效的类名，那么抛出异常。
• 如果 $definition 不属于上述的各种情况，也抛出异常。

总之，对于 $_definitions 数组中的元素，它要么是一个包含了”class” 元素的数组，要么是一个PHP callable， 再要么就是一个具体对象。这就是规范化后的最终结果。

在调用 normalizeDefinition() 对依赖的定义进行规范化处理后， set() 和 setSingleton() 以传入的 $class 为键，将定义保存进 $_definition[] 中， 将传入的 $param 保存进 $_params[] 中。

对于 set() 而言，还要删除 $_singleton[] 中的同名依赖。 对于 setSingleton() 而言，则要将 $_singleton[] 中的同名依赖设为 null ， 表示定义了一个Singleton，但是并未实现化。

这么讲可能不好理解，举几个具体的依赖定义及相应数组的内容变化为例，以加深理解:

 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
35
36
37
38
39
40
41
42
43
44
45

$container = new \yii\di\Container;

// 直接以类名注册一个依赖，虽然这么做没什么意义。
// $_definition['yii\db\Connection'] = 'yii\db\Connetcion'
$container->set('yii\db\Connection');

// 注册一个接口，当一个类依赖于该接口时，定义中的类会自动被实例化，并供
// 有依赖需要的类使用。
// $_definition['yii\mail\MailInterface', 'yii\swiftmailer\Mailer']
$container->set('yii\mail\MailInterface', 'yii\swiftmailer\Mailer');

// 注册一个别名，当调用$container->get('foo')时，可以得到一个
// yii\db\Connection 实例。
// $_definition['foo', 'yii\db\Connection']
$container->set('foo', 'yii\db\Connection');

// 用一个配置数组来注册一个类，需要这个类的实例时，这个配置数组会发生作用。
// $_definition['yii\db\Connection'] = [...]
$container->set('yii\db\Connection', [
    'dsn' => 'mysql:host=127.0.0.1;dbname=demo',
    'username' => 'root',
    'password' => '',
    'charset' => 'utf8',
]);

// 用一个配置数组来注册一个别名，由于别名的类型不详，因此配置数组中需要
// 有 class 元素。
// $_definition['db'] = [...]
$container->set('db', [
    'class' => 'yii\db\Connection',
    'dsn' => 'mysql:host=127.0.0.1;dbname=demo',
    'username' => 'root',
    'password' => '',
    'charset' => 'utf8',
]);

// 用一个PHP callable来注册一个别名，每次引用这个别名时，这个callable都会被调用。
// $_definition['db'] = function(...){...}
$container->set('db', function ($container, $params, $config) {
    return new \yii\db\Connection($config);
});

// 用一个对象来注册一个别名，每次引用这个别名时，这个对象都会被引用。
// $_definition['pageCache'] = anInstanceOfFileCache
$container->set('pageCache', new FileCache);

setSingleton() 对于 $_definition 和 $_params 数组产生的影响与 set() 是一样一样的。 不同之处在于，使用 set() 会unset $_singltons 中的对应元素，Yii认为既然你都调用 set() 了，说明你希望这个依赖不再是单例了。 而 setSingleton() 相比较于 set() ，会额外地将 $_singletons[$class] 置为 null 。 以此来表示这个依赖已经定义了一个单例，但是尚未实例化。

从 set() 和 setSingleton() 来看， 可能还不容易理解DI容器，比如我们说DI容器中维护了5个数组，但是依赖注册过程只涉及到其中3个。 剩下的 $_reflections 和 $_dependencies 是在解析依赖的过程中完成构建的。

从DI容器的5个数组来看也好，从容器定义了 set() 和 setSingleton() 两个定义依赖的方法来看也好， 不难猜出DI容器中装了两类实例，一种是单例，每次向容器索取单例类型的实例时，得到的都是同一个实例； 另一类是普通实例，每次向容器索要普通类型的实例时，容器会根据依赖信息创建一个新的实例给你。

单例类型主要用于节省构建实例的时间、节省保存实例的内存、共享数据等。而普通类型主要用于避免数据冲突。

对象的实例化¶

对象的实例化过程要比依赖的定义过程复杂得多。毕竟依赖的定义只是往特定的数据结构 $_singletons $_definitions 和 $_params 3个数组写入有关的信息。 稍复杂的东西也就是定义的规范化处理了。其它真没什么复杂的。像你这么聪明的，肯定觉得这太没挑战了。

而对象的实例化过程要相对复杂，这一过程会涉及到复杂依赖关系的解析、涉及依赖单元的实例化等过程。 且让我们抽丝剥茧地进行分析。

 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
35
36
37
38
39
40

protected function getDependencies($class)
{
    // 如果已经缓存了其依赖信息，直接返回缓存中的依赖信息
    if (isset($this->_reflections[$class])) {
        return [$this->_reflections[$class], $this->_dependencies[$class]];
    }

    $dependencies = [];

    // 使用PHP5 的反射机制来获取类的有关信息，主要就是为了获取依赖信息
    $reflection = new ReflectionClass($class);

    // 通过类的构建函数的参数来了解这个类依赖于哪些单元
    $constructor = $reflection->getConstructor();
    if ($constructor !== null) {
        foreach ($constructor->getParameters() as $param) {
            if ($param->isDefaultValueAvailable()) {

                // 构造函数如果有默认值，将默认值作为依赖。即然是默认值了，
                // 就肯定是简单类型了。
                $dependencies[] = $param->getDefaultValue();
            } else {
                $c = $param->getClass();

                // 构造函数没有默认值，则为其创建一个引用。
                // 就是前面提到的 Instance 类型。
                $dependencies[] = Instance::of($c === null ? null :
                    $c->getName());
            }
        }
    }

    // 将 ReflectionClass 对象缓存起来
    $this->_reflections[$class] = $reflection;

    // 将依赖信息缓存起来
    $this->_dependencies[$class] = $dependencies;

    return [$reflection, $dependencies];
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

protected function resolveDependencies($dependencies, $reflection = null)
{
    foreach ($dependencies as $index => $dependency) {

        // 前面getDependencies() 函数往 $_dependencies[] 中
        // 写入的是一个 Instance 数组
        if ($dependency instanceof Instance) {
            if ($dependency->id !== null) {

                // 向容器索要所依赖的实例，递归调用 yii\di\Container::get()
                $dependencies[$index] = $this->get($dependency->id);
            } elseif ($reflection !== null) {
                $name = $reflection->getConstructor()
                    ->getParameters()[$index]->getName();
                $class = $reflection->getName();
                throw new InvalidConfigException(
                "Missing required parameter \"$name\" when instantiating \"$class\".");
            }
        }
    }
    return $dependencies;
}

 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
35
36
37

protected function build($class, $params, $config)
{
    // 调用上面提到的getDependencies来获取并缓存依赖信息，留意这里 list 的用法
    list ($reflection, $dependencies) = $this->getDependencies($class);

    // 用传入的 $params 的内容补充、覆盖到依赖信息中
    foreach ($params as $index => $param) {
        $dependencies[$index] = $param;
    }

    // 这个语句是两个条件：
    // 一是要创建的类是一个 yii\base\Object 类，
    // 留意我们在《Yii基础》一篇中讲到，这个类对于构造函数的参数是有一定要求的。
    // 二是依赖信息不为空，也就是要么已经注册过依赖，
    // 要么为build() 传入构造函数参数。
    if (!empty($dependencies) && is_a($class, 'yii\base\Object', true)) {
        // 按照 Object 类的要求，构造函数的最后一个参数为 $config 数组
        $dependencies[count($dependencies) - 1] = $config;

        // 解析依赖信息，如果有依赖单元需要提前实例化，会在这一步完成
        $dependencies = $this->resolveDependencies($dependencies, $reflection);

        // 实例化这个对象
        return $reflection->newInstanceArgs($dependencies);
    } else {
        // 会出现异常的情况有二：
        // 一是依赖信息为空，也就是你前面又没注册过，
        // 现在又不提供构造函数参数，你让Yii怎么实例化？
        // 二是要构造的类，根本就不是 Object 类。
        $dependencies = $this->resolveDependencies($dependencies, $reflection);
        $object = $reflection->newInstanceArgs($dependencies);
        foreach ($config as $name => $value) {
            $object->$name = $value;
        }
        return $object;
    }
}

 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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

public function get($class, $params = [], $config = [])
{
    // 已经有一个完成实例化的单例，直接引用这个单例
    if (isset($this->_singletons[$class])) {
        return $this->_singletons[$class];

    // 是个尚未注册过的依赖，说明它不依赖其他单元，或者依赖信息不用定义，
    // 则根据传入的参数创建一个实例
    } elseif (!isset($this->_definitions[$class])) {
        return $this->build($class, $params, $config);
    }

    // 注意这里创建了 $_definitions[$class] 数组的副本
    $definition = $this->_definitions[$class];

    // 依赖的定义是个 PHP callable，调用之
    if (is_callable($definition, true)) {
        $params = $this->resolveDependencies($this->mergeParams($class,
            $params));
        $object = call_user_func($definition, $this, $params, $config);

    // 依赖的定义是个数组，合并相关的配置和参数，创建之
    } elseif (is_array($definition)) {
        $concrete = $definition['class'];
        unset($definition['class']);

        // 合并将依赖定义中配置数组和参数数组与传入的配置数组和参数数组合并
        $config = array_merge($definition, $config);
        $params = $this->mergeParams($class, $params);

        if ($concrete === $class) {
            // 这是递归终止的重要条件
            $object = $this->build($class, $params, $config);
        } else {
            // 这里实现了递归解析
            $object = $this->get($concrete, $params, $config);
        }

    // 依赖的定义是个对象则应当保存为单例
    } elseif (is_object($definition)) {
        return $this->_singletons[$class] = $definition;
    } else {
        throw new InvalidConfigException(
            "Unexpected object definition type: " . gettype($definition));
    }

    // 依赖的定义已经定义为单例的，应当实例化该对象
    if (array_key_exists($class, $this->_singletons)) {
        $this->_singletons[$class] = $object;
    }

    return $object;
}

实例分析¶

为了加深理解，我们以官方文档上的例子来说明DI容器解析依赖的过程。假设有以下代码:

 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
35
36
37
38
39

namespace app\models;

use yii\base\Object;
use yii\db\Connection;

// 定义接口
interface UserFinderInterface
{
    function findUser();
}

// 定义类，实现接口
class UserFinder extends Object implements UserFinderInterface
{
    public $db;

    // 从构造函数看，这个类依赖于 Connection
    public function __construct(Connection $db, $config = [])
    {
        $this->db = $db;
        parent::__construct($config);
    }

    public function findUser()
    {
    }
}

class UserLister extends Object
{
    public $finder;

    // 从构造函数看，这个类依赖于 UserFinderInterface接口
    public function __construct(UserFinderInterface $finder, $config = [])
    {
        $this->finder = $finder;
        parent::__construct($config);
    }
}

从依赖关系看，这里的 UserLister 类依赖于接口 UserFinderInterface ， 而接口有一个实现就是 UserFinder 类，但这类又依赖于 Connection 。

那么，按照一般常规的作法，要实例化一个 UserLister 通常这么做:

$db = new \yii\db\Connection(['dsn' => '...']);
$finder = new UserFinder($db);
$lister = new UserLister($finder);

就是逆着依赖关系，从最底层的 Connection 开始实例化，接着是 UserFinder 最后是 UserLister 。 在写代码的时候，这个前后顺序是不能乱的。而且，需要用到的单元，你要自己一个一个提前准备好。 对于自己写的可能还比较清楚，对于其他团队成员写的，你还要看他的类究竟是依赖了哪些，并一一实例化。 这种情况，如果是个别的、少量的还可以接受，如果有个10－20个的，那就麻烦了。 估计光实例化的代码，就可以写满一屏幕了。

而且，如果是团队开发，有些单元应当是共用的，如邮件投递服务。 不能说你写个模块，要用到邮件服务了，就自己实例化一个邮件服务吧？那样岂不是有N模块就有N个邮件服务了？ 最好的方式是使邮件服务成为一个单例，这样任何模块在需要邮件服务时，使用的其实是同一个实例。 用传统的这种实例化对象的方法来实现的话，就没那么直接了。

那么改成DI容器的话，应该是怎么样呢？他是这样的:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

use yii\di\Container;

// 创建一个DI容器
$container = new Container;

// 为Connection指定一个数组作为依赖，当需要Connection的实例时，
// 使用这个数组进行创建
$container->set('yii\db\Connection', [
    'dsn' => '...',
]);

// 在需要使用接口 UserFinderInterface 时，采用UserFinder类实现
$container->set('app\models\UserFinderInterface', [
    'class' => 'app\models\UserFinder',
]);

// 为UserLister定义一个别名
$container->set('userLister', 'app\models\UserLister');

// 获取这个UserList的实例
$lister = $container->get('userLister');

采用DI容器的办法，首先各 set() 语句没有前后关系的要求， set() 只是写入特定的数据结构， 并未涉及具体依赖关系的解析。所以，前后关系不重要，先定义什么依赖，后定义什么依赖没有关系。

其次，上面根本没有在DI容器中定义 UserFinder 对于 Connection 的依赖。 但是DI容器通过对 UserFinder 构造函数的分析，能了解到这个类会对 Connection 依赖。这个过程是自动的。

最后，上面只有一个 get() 看起来好像根本没有实例化其他如 Connection 单元一样，但事实上，DI容器已经安排好了一切。 在获取 userLister 之前， Connection 和 UserFinder 都会被自动实例化。 其中， Connection 是根据依赖定义中的配置数组进行实例化的。

经过上面的几个 set() 语句之后，DI容器的 $_params 数组是空的， $_singletons 数组也是空的。 $_definintions 数组却有了新的内容:

1
2
3
4
5
6
7
8

$_definitions = [
    'yii\db\Connection' => [
        'class' => 'yii\db\Connection',    // 注意这里
        'dsn' => ...
    ],
    'app\models\UserFinderInterface' => ['class' => 'app\models\UserFinder'],
    'userLister' => ['class' => 'app\models\UserLister']    // 注意这里
];

在调用 get('userLister') 过程中又发生了什么呢？说实话，这个过程不是十分复杂， 但是由于涉及到递归和回溯，写这里的时候，我写了改，改了写，示意图画了好几回，折腾了好久，都不满意， 就怕说不清楚，读者朋友们理解起来费劲。 最后画了一个简单的示意图，请你们对照 DI容器解析依赖获取实例的过程示意图 ， 以及前面关于 get() build() getDependencies() resolveDependencies() 等函数的源代码， 了解大致流程。如果有任何疑问、建议，也请在底部留言。

DI容器解析依赖获取实例的过程示意图

在 DI容器解析依赖获取实例的过程示意图 中绿色方框表示DI容器的5个数组，浅蓝色圆边方框表示调用的函数和方法。 蓝色箭头表示读取内存，红色箭头表示写入内存，虚线箭头表示参照的内存对象，粗线绿色箭头表示回溯过程。 图中3个圆柱体表示实例化过程中，创建出来的3个实例。

对于 get() 函数：

• 在第1步中调用 get('userLister') 表示要获得一个 userLister 实例。 这个 userLister 不是一个有效的类名，说明这是一个别名。 那么要获取的是这个别名所代表的类的实例。
• 查找 $_definitions 数组，发现 $_definitions['userLister'] = ['class'=>'app\models\UserLister'] 。 这里 userLister 不等于 app\models\UserLister ， 说明要获取的这个 userLister 实例依赖于 app\models\UserLister 。 这是查找依赖定义数组的第一种情况。
• 而在第22、23步中， get(yii\db\Connection) 调用 get() 时指定要获取的实例的类型， 与依赖定义数组 $_definitions 定义的所依赖的类型是相同的，都是 yii\db\Connection 。 也就是说，自己依赖于自己，这就基本达到了停止递归调用 get() 的条件，差不多可以开始反溯了。 这是查找依赖定义数组的第二种情况。
• 第三种情况是第3、4步、第13、14步查找依赖定义数组，发现依赖不存在。 说明所要获取的类型的依赖关系未在容器中注册。 对于未注册依赖关系的，DI容器认为要么是一个没有外部依赖的简单类型， 要么是一个容器自身可以自动解析其依赖关系的类型。
• 对于第一种情况，要获取的类型依赖于其他类型的，递归调用 get() 获取所依赖的类型。
• 对于第二、三种情况，直接调用 build() 尝试获取该类型的实例。

build() 在实例化过程中，干了这么几件事：

• 调用 getDependencies() 获取依赖信息。
• 调用 resolveDependencies() 解析依赖信息。
• 将定义中的配置数组、构造函数参数与调用 get() 时传入的配置数组和构造参数进行合并。 这一步并未在上面的示意图中体现，请参阅 build() 的源代码部分。
• 根据解析回来的依赖单元，调用 newInstanceArgs() 创建实例。 请留意第36、42步，并非直接由 resolveDependencies() 调用 newInstanceArgs() 。 而是 resolveDependencies() 将依赖单元返回后，由 build() 来调用。就像第31步一样。
• 将获取的类型实例返回给调用它的 get() 。

getDependencies() 函数总是被 build() 调用，他干了这么几件事：

• 创建ReflectionClass，并写入 $_reflections 缓存数组。如第6步中， $_reflections['app\models\UserLister'] = new ReflectionClass('app\models\UserLister') 。
• 利用PHP的Reflection API，通过分析构造函数的形式参数，了解到当前类型对于其他单元、默认值的依赖。
• 将上一步了解到的依赖，在 $_dependencies 缓存数组中写入一个 Instance 实例。如第7、8步。
• 当一个类型的构造函数的参数列表中，没有默认值、参数都是简单类型时，得到一个 [null] 。 如第28步。

resolveDependencies() 函数总是被 build() 调用，他在实例化时，干了这么几件事：

• 根据缓存在 $_dependencies 数组中的 Instance 实例的 id ， 递归调用容器的 get() 实例化依赖单元。并返回给 build() 接着运行。
• 对于像第28步之类的依赖信息为 [null] 的，则什么都不干。

newInstanceArgs() 函数是PHP Reflection API的函数，用于创建实例，具体请看 PHP手册 。

这里只是简单的举例子而已，还没有涉及到多依赖和单例的情形，但是在原理上是一样的。 希望继续深入了解的读者朋友可以再看看上面有关函数的源代码就行了，有疑问请随时留言。

从上面的例子中不难发现，DI容器维护了两个缓存数组 $_reflections 和 $_dependencies 。这两个数组只写入一次，就可以无限次使用。 因此，减少了对ReflectionClass的使用，提高了DI容器解析依赖和获取实例的效率。

另一方面，我们看到，获取一个实例，步骤其实不少。但是，对于典型的Web应用而言， 有许多模块其实应当注册为单例的，比如上面的 yii\db\Connection 。 一个Web应用一般使用一个数据库连接，特殊情况下会用多几个，所以这些数据库连接一般是给定不同别名加以区分后， 分别以单例形式放在容器中的。因此，实际获取实例时，步骤会简单得。对于单例， 在第一次 get() 时，直接就返回了。而且，省去不重复构造实例的过程。

这两个方面，都体现出Yii高效能的特点。

上面我们分析了DI容器，这只是其中的原理部分，具体的运用，我们将结合 服务定位器（Service Locator） 来讲。