Laravel 4如何加载延迟的提供程序? [英] How does Laravel 4 load deferred provider?

问题描述

我需要深刻理解laravel.自从我们开始使用laravel以来，我必须向开发团队解释一切.

I need to deeply understand laravel. I have to explain everything to my dev team since we are starting to use laravel.

如果错误，请更正此问题:laravel启动时，由于性能提高，它将服务提供者分为急切"和递延"，然后注册了所有急切"提供者，而不是递延".

Please correct this if it is wrong: When laravel start, due to increasing performance, it split services provider to 'eager' and 'deferred', then it register all 'eager' provider, but not 'deferred'.

我的问题: 每次我们使用延期服务时，例如:

My question: Each time we use deferred services, e.g:

$validator = Validator::make(
    //..
);

laravel如何加载和注册该类/服务?我只是发现这可能与Illuminate\Foundation\ProviderRepository类

How does laravel load and register that class/services ? I just find this probably related line 70 on Illuminate\Foundation\ProviderRepository Class

$app->setDeferredServices($manifest['deferred']);

但是后来我坚持了下来.对不起，英语不好，希望大家都能理解.谢谢.

But then I stuck. Sorry for bad English, hope you all understands. Thanks.

推荐答案

我也想知道答案，但是我决定自己找自己.

I wanted to know the answer to this as well, but I decided to look for myself instead.

如果转到app/storage/meta，则有一个services.json列出了eager和deferred类.这样一来，我们就不会为每个请求加载所有类，因为在构建API时可能永远不需要Form类.

If you go to app/storage/meta there is a services.json that lists the eager and deferred classes. This is so we don't load all classes for every request as we may never need the Form class if we are building an API.

ProviderRepository类扫描app/config/app.php中列出的所有提供程序，并实例化每个提供程序的提供程序(这些不是实际的库).

The ProviderRepository class scans all the providers listed in app/config/app.php and instantiates the providers for each of them (These are not the actual libraries).

这些提供程序，例如Illuminate/Cache中的CacheServiceProvider，具有一个名为defer的变量，该变量确定是否急切地加载该库直到需要时才进行.

These providers eg CacheServiceProvider in Illuminate/Cache have a variable called defer that determines whether the library will be eagerly loaded of deferred until needed.

这是ProviderRepository

重新编译服务清单时，我们将逐个浏览 提供程序，并检查它是否为延迟提供程序.如果是这样 我们将其提供的服务添加到清单中，并注意 提供者.

When recompiling the service manifest, we will spin through each of the providers and check if it's a deferred provider or not. If so we'll add it's provided services to the manifest and note the provider.

对于CacheServiceProvider，此设置为true.

所以可以说Validator::make()叫做这里，这是我收集到的；每个Facade(例如Validator门面)都扩展了Illuminate\Support\Facades\Facade中的基础Facade类.

So lets say Validator::make() is called here is what I have gathered; Each Facade such as the Validator facade extends the base Facade class in Illuminate\Support\Facades\Facade.

这有一个神奇的方法__callStatic($method, $args)，它很容易解释，这种方法的重点是

This has a magic method __callStatic($method, $args) which is quite self explanatory, the main point of this method is

$instance = static::resolveFacadeInstance(static::getFacadeAccessor());

在这种情况下，facade访问器返回执行验证的实际类的字符串(Illuminate\Validation\Validator):

The facade accessor in this case returns a string of the actual class that performs the validation (Illuminate\Validation\Validator):

protected static function getFacadeAccessor() { return 'validator'; }

主要方法resolveFacadeInstance检查返回的访问器是否是一个对象.如果是这样，它可能只是将其返回，因为它可能是自定义的Laravel软件包.

The main method resolveFacadeInstance checks if the returned accessor is an object. If it is it simply returns that back as it is probably a custom Laravel package.

此方法的第二部分检查它是否已解决，然后返回.最后一部分:

The second part of this method checks if it has already been resolved, if it has then return that. The final part:

return static::$resolvedInstance[$name] = static::$app[$name];

通过调用Illuminate\Foundation\Application(扩展了Illuminate\Container\Container类).位于前面提到的父类中的数组访问接口.

Calls the Illuminate\Foundation\Application (which extends the Illuminate\Container\Container class) via the array access interface located in the previously mentioned parent class.

所以static::$app[$name]呼叫:

public function offsetGet($key)
{
    return $this->make($key);
}

这位于Container类

这将我们带到Application类中的make()方法:

Which leads us to the make() method in the Application class:

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

    return parent::make($abstract, $parameters);
}

我将让您深入研究parent::make()方法，因为这将开始变得很冗长，但就目前情况而言，这是加载延迟的提供程序并通过loadDeferredProvider()

I'll let you delve into the parent::make() method as this would start getting very lengthy, but as it stands this is where it loads the deferred provider and instantiates it via the loadDeferredProvider()

public function loadDeferredProviders()
{
    // We will simply spin through each of the deferred providers and register each
    // one and boot them if the application has booted. This should make each of
    // the remaining services available to this application for immediate use.
    foreach (array_unique($this->deferredServices) as $provider)
    {
        $this->register($instance = new $provider($this));

        if ($this->booted) $instance->boot();
    }

    $this->deferredServices = array();
}

代码块中的注释应解释其余情况.

从这里开始，__callStatic($method, $args)的最后一部分触发称为Validator::make()的实际方法.

From here, the last part of __callStatic($method, $args) fires the actual method called Validator::make().

public static function __callStatic($method, $args)
{
    $instance = static::resolveFacadeInstance(static::getFacadeAccessor());

    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(array($instance, $method), $args);
    }
}

所以外观调用了Illuminate\Validation\Validator的非静态方法validate().

So the facade calls Illuminate\Validation\Validator's non-static method validate().

我很确定这对于4.0是正确的，但是如果有任何错误，请纠正我.

这篇关于Laravel 4如何加载延迟的提供程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！