laravel中facade serviceprovider的理解

一个serviceprovider就是一个解决某个功能的公用模块，实际上可以直接用在di里注册然后从di中取出，为啥还要搞个facade呢？

有几个方面的原因

1、把实例化移入到serviceprovider，自己负责自己的初始化，这样简化代码，di注册的地方更加简洁

class SomeServiceProvider extends ServiceProvider {

  public function register() {

      $this->app->bind('some', new Some());

  }

}

在register里直接实例化对象

2、使用facade可以方便更换serviceprovider，只要它们提供的方法一致。

比如我们有个日志服务，如采用facade的方式，那么当觉得这个日志服务性能不够好时，想更换更好的日志服务，直接在getFacadeAccessor里更换对应的服务类名即可，而不用大改项目里的代码

如redis的Facade

protected static function getFacadeAccessor()

    {

        return 'redis';

    }

3、方便调用函数，可以直接用静态方法调用，因为facade实际调用的是serviceprovider对象

这是facade的中__callStatic函数，可见实际是调用serviceprovider实例

 /**

     * Handle dynamic, static calls to the object.

     *

     * @param  string  $method

     * @param  array   $args

     * @return mixed

     */

    public static function __callStatic($method, $args)

    {

        $instance = static::getFacadeRoot();

        if (! $instance) {

            throw new RuntimeException('A facade root has not been set.');

        }

        switch (count($args)) {

            case 0:

                return $instance->$method();

            case 1:

                return $instance->$method($args[0]);

            case 2:

                return $instance->$method($args[0], $args[1]);

            case 3:

                return $instance->$method($args[0], $args[1], $args[2]);

            case 4:

                return $instance->$method($args[0], $args[1], $args[2], $args[3]);

            default:

                return call_user_func_array([$instance, $method], $args);

        }

    }

有一利则有一弊，调用嵌套太多，理解起来复杂，而且我觉得速度上也会减慢，当然现在的大型网站速度瓶颈都在数据库io上，这点效率损失还是可以接受的。

4、调用流程为Facade--> serviceprovider --

Facade会加载serviceprovider 实例化register 返回的对象 SomeObject

调用时SomeCalss::method，会Facade::__callStatic ，即 object->menthod

facade 相当于把di调用的di->get("some")->method()简化了

serviceprovider 则相当于简化di的配置，即di->add(someComeponent,config)

会读取config目录下的所有

巴特西

laravel中facade serviceprovider的理解

最新文章

热门文章