如何理解 Laravel 和 ThinkPHP 5 中的服务容器与注入？

栏目: PHP · 发布时间: 4年前

内容简介：很多人一开始看到官方的文档，无论是 Laravel 还是 ThinkPHP ，看完都是一头雾水，不求甚解。甚至都是直接跳过去，不看，，如果在短时间内有这个念头很正常，尤其是习惯了 ThinkPHP 3 的使用者，相对引入的理念比较前沿，如果你在长时间内都不去考虑去理解，那就要看你自己的职业规划了。接下来就来一起看一下，细细追品。

从文档说起

很多人一开始看到官方的文档，无论是 Laravel 还是 ThinkPHP ，看完都是一头雾水，不求甚解。甚至都是直接跳过去，不看，

~~反正我也不一样用得到这么高端的东西~~

，如果在短时间内有这个念头很正常，尤其是习惯了 ThinkPHP 3 的使用者，相对引入的理念比较前沿，如果你在长时间内都不去考虑去理解，那就要看你自己的职业规划了。

接下来就来一起看一下，细细追品。

从 Laravel 开始

从 Laravel 的文档中看到有 bind 、 singleton 以及 instance ，这三个常用方法，接下来就一一解答。

实际应用

假设我们有这样一个场景，当我们用户在进行注册时，我们需要向用户手机发送一条短信验证码，然后当用户收到验证码后在注册表单提交时还需要验证验证码是否正确。

这个需求看起来非常容易实现，对吧？

当我们拿到短信平台的开发文档后，我们只需要写出两个方法。 send 和 check 分别用来发送验证码和校验验证码，下面就在不用容器的情况下来写一下伪代码。

MeiSms.php

<?php


namespace App\Tools;


class MeiSms
{
    public function send($phone)
    {
        $code = mt_rand(1e3, 1e4 - 1);
        // TODO ... 通过接口发送
        // 存放验证码到 Redis
        $cacheManager = cache();
        // 设定 5 分钟失效
        $cacheManager->set('sms:' . $phone, $code, 5 * 60);
        return true;
    }

    public function check($phone, $code)
    {
        $cacheManager = cache();
        return $cacheManager->get('sms:' . $phone) === $code;
    }
}

很容易，不是吗？

然后在控制器中 new 一个 MeiSms 的实例，直接调用 send 和 check 就可以分别发送和检查验证码了。

但是，如果运营突然反馈说，之前给的短信平台不可靠，发送短信不稳定，用户经常收不到。

这时候我们就需要换一个接口，常见的方式就是我们再写一个对象，然后又可能这个代码是别人写的让你来接收，你觉得 send 或者 check 这个方法名不够规范，然后你就给改了，然后顺带把原来的注册那边一并改了，然后代码就突突上线，跑起来了。

然后没过多久，运营又觉得这个平台的短信太贵了，另外又找到了一家既便宜又稳定的一家，然后你又重复了上面的事情，这次，方法这些你都觉得很完美，不用改动。

只是需要写一写方法体，然后在调用的地方改一些new 时的类名。

当然，这只是一个小例子，开发过程中我们可能还会遇到比这复杂的多的改动，又或者，运营又想让你换回之前的版本？emm。

在这里，如果有了解过简单工厂模式的朋友，可能会想到我可以使用简单工厂模式来搞定这个啊。

function factory($name)
{
    $modules = [
        'sms' => new MeiSms(),
    ];
    if (!isset($modules[$name])) {
        throw new \Exception('对象不存在。');
    }
    return $modules[$name];
}

在需要的地方直接调用 factory('sms') 这样就能拿到一个发送短信的对象，当需求改了后，我直接改造一下工厂就好了，不是也简单了很多。

但是，到这里你会发现一些问题，工厂生产出来的对象没有类型提示，而且我们在工厂内没办法限制类必须要实现哪些方法(当然你可以把工厂搞的更复杂，加上接口校验)，但是到头来你会发现，这里我们最初要做的事儿越来越远，而且，越来越复杂，不是吗？而且，工厂也不是那么的易用。

服务容器

这里就要看回我们的 服务容器 ，首先我们先看看控制器的文档中关于依赖注入部分的说明，这也是很多人最开始了解到 依赖注入 的地方。

构造函数注入

Laravel 服务容器解析所有的控制器。因此，你可以在控制器的构造函数中使用类型提示可能需要的依赖项。依赖声明会被自动解析并注入到控制器实例

方法注入

处理构造函数注入，你还可以在控制器方法中输入类型提示依赖项。方法注入最常见的用例是在控制器方法中注入 Illuminate\Http\Request 的实例

当我们每次创建一个控制器方法，都会主动填写第一个参数，即 Request $request 你是否有注意过那个 Request 的参数呢？是不是很神奇呢？

为什么我什么都没有做，我就可以使用它，而且，着并不限于 Laravel 内置的对象，我们自己写的对象也是可以的，而且在使用 IDE 开发时我们还可以方便的使用类型提示，这些工作，就是 服务容器 帮我们做的。

当容器解析到这个方法时，当方法存在，就会用反射，来解析这个方法中需要的参数以及参数的类型。

ReflectionFunctionAbstract::getParameters ，然后在容器中查找我们是否 bind 有这个类型，如果没有，就继续使用容器去创建这个类(因为这个类的构造方法中可能还会依赖其他的类)直到所依赖的类实例化完成，并且，把实例存到容器。

到这里你是不是觉得 服务容器 没有卵用？就是帮我们递归实例化类而已。那你就太年轻了，既然上面说到了我们要用 服务容器 来解决 简单工厂 所解决的问题，难倒我还会骗你不成？哈哈

这里就要开始说第一个了 bind

bind 方法

首先我们来看一下 Laravel 中 bind 方法的实现。

/**
     * Register a binding with the container.
     *
     * @param  string  $abstract
     * @param  \Closure|string|null  $concrete
     * @param  bool  $shared
     * @return void
     */
    public function bind($abstract, $concrete = null, $shared = false)
    {
        // If no concrete type was given, we will simply set the concrete type to the
        // abstract type. After that, the concrete type to be registered as shared
        // without being forced to state their classes in both of the parameters.
        $this->dropStaleInstances($abstract);

        if (is_null($concrete)) {
            $concrete = $abstract;
        }

        // If the factory is not a Closure, it means it is just a class name which is
        // bound into this container to the abstract type and we will just wrap it
        // up inside its own Closure to give us more convenience when extending.
        if (! $concrete instanceof Closure) {
            $concrete = $this->getClosure($abstract, $concrete);
        }

        $this->bindings[$abstract] = compact('concrete', 'shared');

        // If the abstract type was already resolved in this container we'll fire the
        // rebound listener so that any objects which have already gotten resolved
        // can have their copy of the object updated via the listener callbacks.
        if ($this->resolved($abstract)) {
            $this->rebound($abstract);
        }
    }
    /**
     * Drop all of the stale instances and aliases.
     *
     * @param  string  $abstract
     * @return void
     */
    protected function dropStaleInstances($abstract)
    {
        unset($this->instances[$abstract], $this->aliases[$abstract]);
    }

    /**
     * Get the Closure to be used when building a type.
     *
     * @param  string  $abstract
     * @param  string  $concrete
     * @return \Closure
     */
    protected function getClosure($abstract, $concrete)
    {
        return function ($container, $parameters = []) use ($abstract, $concrete) {
            if ($abstract == $concrete) {
                return $container->build($concrete);
            }

            return $container->make($concrete, $parameters);
        };
    }

在一开始就调用了 $this->dropStaleInstances($abstract); 追踪源码我们看到，他直接删除了第一个参数对应的已经存在的实例和别名。

然后接着往下，当 $concrete 不是一个 Closure (匿名方法) 时，他会去做一些包装处理成一个匿名方法，最后存入了 bindings 这个属性，键为 $abstract ，值是一个数组，其中 concrete 是包装后的方法，然后调用了容器的 make 。。

当运行到这个位置

if ($this->resolved($abstract)) {
    $this->rebound($abstract);
}

会先去判断这个是否已经解析过了，进行更新已经存放在容器中的副本。

这就是 bind 所干的事儿，描述简单点儿，就是给一个类、类实例、匿名方法提供了一个别名绑定到了容器中去。

当我们使用 resolve 传入刚刚的别名时就能解析拿到我们之前绑定的实例。

赶紧来试试？

我们先打开 bootstrap/app.php ，可以看到一开始，就创建了一个 Application 的实例，我们就试着在 $app 被 return 前面给绑定一下。

bootstrap/app.php:54