Laravel 服务容器实例教程 —— 深入理解控制反转（IoC）和依赖

? ? ? ?今天我们着重谈谈什么是IoC？什么是依赖注入？ 为什么要用这些所谓的概念，怎么运用呢？

其实我看到这些关键词的时候，脑子里有一个定论，但是呢，一知半解，也是深受痛苦，怎么才能不痛苦呢，那就是理解他们之间的关系、原理，各个击破，这才是最好的办法，不然，看到一次，你后悔一次，看到一次，你头痛一次，那何不来场解剖呢？

下面引用一些各大型公共洗浴场所所提供的资料：

Laravel学院证词：

容器：顾名思义，装东西的东西，通过这种容器，得以实现许多高级功能，其中最长提到的就是“解耦”、“依赖注入”。

IoC容器：Laravel的核心

IoC容器诞生的故事：超人和超能力，依赖的产生

那就有这几样东西无时无刻的接触，接口、类还有对象，接口是类的原型，对象是类实例化后的产物。

创建一个“超人”类

class Superman { }

超人至少拥有一种超能力，这个超能力也可以抽象一个对象，定义为一个类

class Power{

protected $ability;

protected $range;

public function _construct($ability,$range){

$this->ability = $ability;

$this->range = $range;

}

}

回头，修改一下之前的“超人”类，让超人拥有这个超能力：

class Superman{

protected $power;

public function _construct(){

$this->power = new Power(999,100);

}

}

这样超人就拥有了超能力了，就产生了依赖，这样的依赖随处可见，如果这种依赖达到一个量级，是怎样一番噩梦般的体验。

2，假设，超人有多种超能力

• 飞行，属性有：飞行速度、持续飞行时间
• 蛮力，属性有：力量值
• 能量弹，属性有：伤害值、射击距离、同时射击个数

class SuperModuleFactory
{
    public function makeModule($moduleName,$options)
    {
        switch ($moduleName) {
            case 'Fight': 
                return new Fight($options[0],$options[1]);
            case 'Force': 
                return new Force($options[0]);
            case 'Shot': 
                return new Shot($options[0],$options[1],$options[2]);
            // case 'more': .......
            // case 'and more': .......
            // case 'and more': .......
            // case 'oh no! its too many!': .......
        }
    }
}

interface SuperModuleInterface
{
    /**
     * 超能力激活方法
     *
     * 任何一个超能力都得有该方法，并拥有一个参数
     *@param array $target 针对目标，可以是一个或多个，自己或他人
     */
    public function activate(array $target);
}

/**
 * X-超能量
 */
class XPower implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 这只是个例子。。具体自行脑补
    }
}

/**
 * 终极炸弹 （就这么俗）
 */
class UltraBomb implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 这只是个例子。。具体自行脑补
    }
}

class Superman
{
    protected $module;

    public function __construct(SuperModuleInterface $module)
    {
        $this->module = $module;
    }
}

// 超能力模组
$superModule = new XPower;
// 初始化一个超人，并注入一个超能力模组依赖
$superMan = new Superman($superModule);

下面我都接近真相了

更为先进的工厂 —— IoC 容器

刚刚列了一段代码：

$superModule = new XPower;
$superMan = new Superman($superModule);

读者应该看出来了，手动的创建了一个超能力模组、手动的创建超人并注入了刚刚创建超能力模组。呵呵，手动。

现代社会，应该是高效率的生产，干净的车间，完美的自动化装配。

一群怪兽来了，如此低效率产出超人是不现实，我们需要自动化 —— 最多一条指令，千军万马来相见。我们需要一种高级的生产车间，我们只需要向生产车间提交一个脚本，工厂便能够通过指令自动化生产。这种更为高级的工厂，就是工厂模式的升华 —— IoC 容器。

class Container
{
    protected $binds;

    protected $instances;

    public function bind($abstract,$concrete)
    {
        if ($concrete instanceof Closure) {
            $this->binds[$abstract] = $concrete;
        } else {
            $this->instances[$abstract] = $concrete;
        }
    }

    public function make($abstract,$parameters = [])
    {
        if (isset($this->instances[$abstract])) {
            return $this->instances[$abstract];
        }

        array_unshift($parameters,$this);

        return call_user_func_array($this->binds[$abstract],$parameters);
    }
}

这时候，一个十分粗糙的容器就诞生了。现在的确很简陋，但不妨碍我们进一步提升他。先着眼现在，看看这个容器如何使用吧！

// 创建一个容器（后面称作超级工厂）
$container = new Container;

// 向该 超级工厂添加超人的生产脚本
$container->bind('superman',function($container,$moduleName) {
    return new Superman($container->make($moduleName));
});

// 向该 超级工厂添加超能力模组的生产脚本
$container->bind('xpower',function($container) {
    return new XPower;
});

// 同上
$container->bind('ultrabomb',function($container) {
    return new UltraBomb;
});

// ****************** 华丽丽的分割线 **********************
// 开始启动生产
$superman_1 = $container->make('superman','xpower');
$superman_2 = $container->make('superman','ultrabomb');
$superman_3 = $container->make('superman','xpower');
// ...随意添加

看到没？通过最初的 绑定（bind） 操作，我们向 超级工厂 注册了一些生产脚本，这些生产脚本在生产指令下达之时便会执行。发现没有？我们彻底的解除了 超人 与 超能力模组 的依赖关系，更重要的是，容器类也丝毫没有和他们产生任何依赖！我们通过注册、绑定的方式向容器中添加一段可以被执行的回调（可以是匿名函数、非匿名函数、类的方法）作为生产一个类的实例的 脚本 ，只有在真正的 生产（make） 操作被调用执行时，才会触发。

这样一种方式，使得我们更容易在创建一个实例的同时解决其依赖关系，并且更加灵活。当有新的需求，只需另外绑定一个“生产脚本”即可。

实际上，真正的 IoC 容器更为高级。我们现在的例子中，还是需要手动提供超人所需要的模组参数，但真正的 IoC 容器会根据类的依赖需求，自动在注册、绑定的一堆实例中搜寻符合的依赖需求，并自动注入到构造函数参数中去。Laravel 框架的服务容器正是这么做的。实现这种功能其实理论上并不麻烦，但我并不会在本文中写出，因为……我懒得写。

不过我告诉大家，这种自动搜寻依赖需求的功能，是通过反射（Reflection）实现的，恰好的，php 完美的支持反射机制！关于反射，php 官方文档有详细的资料，并且中文翻译基本覆盖，足够学习和研究：

http://php.net/manual/zh/book.reflection.php

现在，到目前为止，我们已经不再惧怕怪兽们了。高智商人才集思广益，井井有条，根据接口契约创造规范的超能力模组。超人开始批量产出。最终，人人都是超人，你也可以是哦！

重新审视 Laravel 的核心

现在，我们开始慢慢解读 Laravel 的核心。其实，Laravel 的核心就是一个 IoC 容器，也恰好是我之前所说的高级的 IoC 容器。

可以说，Laravel 的核心本身十分轻量，并没有什么很神奇很实质性的应用功能。很多人用到的各种功能模块比如 Route（路由）、Eloquent ORM（数据库 ORM 组件）、Request（请求）以及?Response（响应）等等等等，实际上都是与核心无关的类模块提供的，这些类从注册到实例化，最终被你所使用，其实都是 Laravel 的服务容器负责的。

我们以大家最常见的 Route 类作为例子。大家可能经常见到路由定义是这样的：

Route::get('/',function() {
    // bla bla bla...
});

实际上， Route 类被定义在这个命名空间：IlluminateRoutingRouter，文件?vendor/laravel/framework/src/Illuminate/Routing/Router.php。

我们通过打开发现，这个类的这一系列方法，如?get，post，any?等都不是静态（static）方法，这是怎么一回事儿？不要急，我们继续。

服务提供者

我们在前文介绍 IoC 容器的部分中，提到了，一个类需要绑定、注册至容器中，才能被“制造”。

对，一个类要被容器所能够提取，必须要先注册至这个容器。既然 Laravel 称这个容器叫做服务容器，那么我们需要某个服务，就得先注册、绑定这个服务到容器，那么提供服务并绑定服务至容器的东西，就是服务提供者（Service Provider）。

虽然，绑定一个类到容器不一定非要通过服务提供者。

但是，我们知道，有时候我们的类、模块会有需要其他类和组件的情况，为了保证初始化阶段不会出现所需要的模块和组件没有注册的情况，Laravel 将注册和初始化行为进行拆分，注册的时候就只能注册，初始化的时候就是初始化。拆分后的产物就是现在的服务提供者。

服务提供者主要分为两个部分，register（注册） 和?boot（引导、初始化），具体参考文档。register?负责进行向容器注册“脚本”，但要注意注册部分不要有对未知事物的依赖，如果有，就要移步至?boot?部分。

门面（Facade）

我们现在解答之前关于 Route 的方法为何能以静态方法访问的问题。实际上这个问题文档上有写，简单说来就是模拟一个类，提供一个静态魔术方法__callStatic，并将该静态方法映射到真正的方法上。

我们使用的 Route 类实际上是?IlluminateSupportFacadesRoute?通过?class_alias()?函数创造的别名而已，这个类被定义在文件?vendor/laravel/framework/src/Illuminate/Support/Facades/Route.php?。

我们打开文件一看……诶？怎么只有这么简单的一段代码呢？

<?php 
    namespace IlluminateSupportFacades;

    /**
     * @see IlluminateRoutingRouter
     */
    class Route extends Facade {

        /**
         * Get the registered name of the component.
         *
         * @return string
         */
        protected static function getFacadeAccessor()
        {
            return 'router';
        }

}

其实仔细看，会发现这个类继承了一个叫做?Facade?的类，到这里谜底差不多要解开了。

上述简单的定义中，我们看到了?getFacadeAccessor?方法返回了一个?route，这是什么意思呢？事实上，这个值被一个?ServiceProvider?注册过，大家应该知道注册了个什么，当然是那个真正的路由类！

有人会问，Facade?是怎么实现的。我并不想说得太细，一个是我懒，另一个原因就是，自己发现一些东西更容易理解，并不容易忘记。很多细节我已经说了，建议大家自行去研究。

Laravel ?China 的证词：

1、首先，假设要开发一个组件命名为 SomeComponent 。组件中需要注入一个数据库连接。

<?php 
class SomeComponent
{
    public function someDbTask()
    {
        $connection = new Connection(array(
            "host" => "localhost","username" => "root","password" => "secret","dbname" => "invo"
        ));

        // ...
    }

}

$some = new SomeComponent();
$some->someDbTask();

在这个例子中，数据库连接在 component 中被创建，这种方法是不切实际的，如果数据发送变化，事情将变的很难维护。

2、为了解决上面所说的问题，我们需要在使用前创建一个外部连接，并注入到容器中。

<?php
class SomeComponent
{
    protected $_connection;
    public function setConnection($connection)
    {
        $this->_connection = $connection;
    }

    public function someDbTask()
    {
        $connection = $this->_connection;

        // ...
    }

}

$some = new SomeComponent();

//Create the connection
$connection = new Connection(array(
    "host" => "localhost","dbname" => "invo"
));

//Inject the connection in the component
$some->setConnection($connection);

$some->someDbTask();

现在来考虑一个问题，我们在应用程序中的不同地方使用此组件，将多次创建数据库连接，还是那个问题，一旦发生变化，维护度高。所以。。。 3、使用一种类似全局注册表的方式，从中获得一个数据库连接实例，而不是使用一次就创建一次。

<?php
class SomeComponent
{

    protected $_connection;

    /**
     * Sets the connection externally
     */
    public function setConnection($connection){
        $this->_connection = $connection;
    }

    public function someDbTask()
    {
        $connection = $this->_connection;

        // ...
    }

}

class Registry
{

    /**
     * Returns the connection
     */
    public static function getConnection()
    {
       return new Connection(array(
            "host" => "localhost","dbname" => "invo"
        ));
    }

}

$some = new SomeComponent();

//Pass the connection defined in the registry
$some->setConnection(Registry::getConnection());

$some->someDbTask();

4、好了，现在我们需要全局注册表组件里实现两个方法，第一创建一个新的数据库连接，第二总是获得一个共享连接：

<?php

class Registry
{
    protected static $_connection;

    /**
     * Creates a connection
     */
    protected static function _createConnection()
    {
        return new Connection(array(
            "host" => "localhost","dbname" => "invo"
        ));
    }

    /**
     * Creates a connection only once and returns it
     */
    public static function getSharedConnection()
    {
        if (self::$_connection===null){
            $connection = self::_createConnection();
            self::$_connection = $connection;
        }
        return self::$_connection;
    }

    /**
     * Always returns a new connection
     */
    public static function getNewConnection()
    {
        return self::_createConnection();
    }

}

class SomeComponent
{

    protected $_connection;

    /**
     * Sets the connection externally
     */
    public function setConnection($connection){
        $this->_connection = $connection;
    }

    /**
     * This method always needs the shared connection
     */
    public function someDbTask()
    {
        $connection = $this->_connection;

        // ...
    }

    /**
     * This method always needs a new connection
     */
    public function someOtherDbTask($connection)
    {

    }

}

$some = new SomeComponent();

//This injects the shared connection
$some->setConnection(Registry::getSharedConnection());

$some->someDbTask();

//Here,we always pass a new connection as parameter
$some->someOtherDbTask(Registry::getConnection());

到此为止，我们已经看到了如何使用依赖注入解决我们的问题。不是在代码内部创建依赖关系，而是让其作为一个参数传递，这使得我们的程序更容易维护，降低程序代码的耦合度，实现一种松耦合。但是从长远来看，这种形式的依赖注入也有一些缺点。 例如，如果组件中有较多的依赖关系，我们需要创建多个setter方法传递，或创建构造函数进行传递。另外，每次使用组件时，都需要创建依赖组件，使代码维护不太易，我们编写的代码可能像这样：

<?php

//Create the dependencies or retrieve them from the registry
$connection = new Connection();
$session = new Session();
$fileSystem = new FileSystem();
$filter = new Filter();
$selector = new Selector();

//Pass them as constructor parameters
$some = new SomeComponent($connection,$session,$fileSystem,$filter,$selector);

// ... or using setters

$some->setConnection($connection);
$some->setSession($session);
$some->setFileSystem($fileSystem);
$some->setFilter($filter);
$some->setSelector($selector);

我们不得不在应用程序的许多地方创建这个对象。如果你不需要依赖的组件后，我们又要去代码注入部分移除构造函数中的参数或者是setter方法。 5、为了解决这个问题，我们再次返回去使用一个全局注册表来创建组件。但是，在创建对象之前，它增加了一个新的抽象层：

<?php

class SomeComponent
{

    // ...

    /**
     * Define a factory method to create SomeComponent instances injecting its dependencies
     */
    public static function factory()
    {

        $connection = new Connection();
        $session = new Session();
        $fileSystem = new FileSystem();
        $filter = new Filter();
        $selector = new Selector();

        return new self($connection,$selector);
    }

}

这一刻，我们好像回到了问题的开始，我们正在创建组件内部的依赖，我们每次都在修改以及找寻一种解决问题的办法，但这都不是很好的做法。 一种实用和优雅的来解决这些问题，是使用容器的依赖注入，就像我们在前面看到的那样，容器作为全局注册表，使用容器的依赖注入做为一种桥梁来解决依赖可以使我们的代码耦合度更低，很好的降低了组件的复杂性：

<?php

class SomeComponent
{

    protected $_di;

    public function __construct($di)
    {
        $this->_di = $di;
    }

    public function someDbTask()
    {

        // Get the connection service
        // Always returns a new connection
        $connection = $this->_di->get('db');

    }

    public function someOtherDbTask()
    {

        // Get a shared connection service,// this will return the same connection everytime
        $connection = $this->_di->getShared('db');

        //This method also requires a input filtering service
        $filter = $this->_db->get('filter');

    }

}

$di = new PhalconDI();

//Register a "db" service in the container
$di->set('db',function(){
    return new Connection(array(
        "host" => "localhost","dbname" => "invo"
    ));
});

//Register a "filter" service in the container
$di->set('filter',function(){
    return new Filter();
});

//Register a "session" service in the container
$di->set('session',function(){
    return new Session();
});

//Pass the service container as unique parameter
$some = new SomeComponent($di);

$some->someTask();

现在，该组件只有访问某种service的时候才需要它，如果它不需要，它甚至不初始化，以节约资源。该组件是高度解耦。他们的行为，或者说他们的任何其他方面都不会影响到组件本身。 6、现在，剩下的就是 PhalconDI 这个全局容器了。

PhalconDI 是一个实现了服务的依赖注入功能的组件，它本身就是一个容器。由于Phalcon高度解耦，PhalconDI 是框架用来集成其他组件的必不可少的部分，开发人员也可以使用这个组件依赖注入和管理应用程序中不同类文件的实例。

基本上，这个组件实现了 Inversion of Control 模式。基于此，对象不再以构造函数接收参数或者使用setter的方式来实现注入，而是直接请求服务的依赖注入。这就大大降低了整体程序的复杂性，因为只有一个方法用以获得所需要的一个组件的依赖关系。

这种模式增强了代码的可测试性，从而使它不容易出错。在容器中注册服务，框架本身或开发人员都可以注册服务。当一个组件A要求调用组件B（或它的类的一个实例），可以从容器中请求调用组件B，而不是创建组件B的一个实例。

这种工作方式为我们提供了许多优点：

我们可以更换一个组件，从他们本身或者第三方轻松创建。 在组件发布之前，我们可以充分的控制对象的初始化，并对对象进行各种设置。 我们可以使用统一的方式从组件得到一个结构化的全局实例

7、服务可以通过以下几种方式注入到容器：

<?php

//Create the Dependency Injector Container
$di = new PhalconDI();

//By its class name
$di->set("request",'PhalconHttpRequest');

//Using an anonymous function,the instance will lazy loaded
$di->set("request",function(){
    return new PhalconHttpRequest();
});

//Registering  an instance
$di->set("request",new PhalconHttpRequest());

//Using an array definition
$di->set("request",array(
    "className" => 'PhalconHttpRequest'
));

现在看代码，你有没有看到 Laravel 的影子呢，在上面的例子中，当向框架请求访问一个请求数据时，它将首先确定容器中是否存在这个”reqeust”名称的服务。 容器会反回一个请求数据的实例，开发人员最终得到他们想要的组件。

在上面示例中的每一种方法都有优缺点，具体使用哪一种，由开发过程中的特定场景来决定的。

用一个字符串来设定一个服务非常简单，但缺少灵活性。设置服务时，使用数组则提供了更多的灵活性，而且可以使用较复杂的代码。lambda函数是两者之间一个很好的平衡，但也可能导致更多的维护管理成本。

PhalconDI 提供服务的延迟加载。除非开发人员在注入服务的时候直接实例化一个对象，然后存存储到容器中。在容器中，通过数组，字符串等方式存储的服务都将被延迟加载，即只有在请求对象的时候才被初始化。

<?php

//Register a service "db" with a class name and its parameters
$di->set("db",array(
    "className" => "PhalconDbAdapterPdoMysql","parameters" => array(
          "parameter" => array(
               "host" => "localhost","dbname" => "blog"
          )
    )
));

//Using an anonymous function
$di->set("db",function(){
    return new PhalconDbAdapterPdoMysql(array(
         "host" => "localhost","dbname" => "blog"
    ));
});

以上这两种服务的注册方式产生相同的结果。然后，通过数组定义的，在后面需要的时候，你可以修改服务参数：

<?php

$di->setParameter("db",array(
    "host" => "localhost","password" => "secret"
));

从容器中获得服务的最简单方式就是使用”get”方法，它将从容器中返回一个新的实例：

<?php $request = $di->get("request");

或者通过下面这种魔术方法的形式调用：

<?php
    $request = $di->getRequest();

PhalconDI 同时允许服务重用，为了得到一个已经实例化过的服务，可以使用 getShared() 方法的形式来获得服务。

参数还可以在请求的时候通过将一个数组参数传递给构造函数的方式：

<?php
    $component = $di->get("MyComponent",array("some-parameter","other"))

想必：你应该了解一些其中的奥秘了，未完待续......