Récupérer l'instance de conteneur dans le code (Laravel)

Cet article est écrit par la colonne tutorielle laravel pour présenter comment obtenir l'instance de conteneur dans le code. J'espère qu'il sera utile aux amis qui en ont besoin !

L'instance de conteneur Laravel est unique tout au long du cycle de vie de la demande et gère toutes les instances de composants de service. Alors, quels sont les moyens d'obtenir une instance du conteneur Laravel ? Les méthodes suivantes sont couramment utilisées :

1) Via la fonction d'aide de l'application :

$app = app();

La fonction auxiliaire de l'application est définie dans le fichier

Ce fichier définit de nombreuses fonctions d'aide et sera automatiquement chargé dans le fichier

. fichier via le projet composer. Par conséquent, les fonctions sont accessibles à n’importe quel emplacement de code impliqué dans le traitement des requêtes http, tel que app().

2) Via l'App Facade

<?php
Route::get(&#39;/&#39;, function () {
    dd(App::basePath());
    return &#39;&#39;;
});

La façon d'obtenir l'instance de conteneur via l'App Facade est différente de celle ci-dessus. Vous ne pouvez pas d'abord attribuer l'application à une variable, puis appeler la méthode du conteneur via la variable. En effet, App n'est qu'un nom de classe et nous ne pouvons pas copier un nom de classe dans une variable. $app = App; n'est pas une instruction exécutable légale, mais $app = app(); est une instruction exécutable légale, car elle est suivie par app(), indiquant un appel de fonction. App::basePath(); est également une déclaration légale, elle appelle la méthode statique de la classe.

Ajoutez 2 points supplémentaires :

Premier point : Facade est une fonctionnalité particulière du framework laravel. Chaque Facade sera associée à un objet instance dans le conteneur. Nous pouvons l'appeler directement via l'appel de méthode statique de la classe Facade. Méthodes de l'objet instance auquel il est associé. Par exemple, la façade de l'application, lors de l'appel de App::basePath(), est en fait équivalente à app()->basePath().

Ce mécanisme sous-jacent s'appuie également sur les caractéristiques du langage PHP. Il doit définir un membre statique dans chaque Facade et l'associer à un objet instance du service. Lorsque la méthode statique de la classe Facade est appelée, l'appel est effectué. nom de la méthode analysé, puis appelez la méthode du même nom de l'instance de service associée, et enfin renvoyez le résultat.

Je pense qu'il suffit de comprendre quel rôle Facade peut jouer. Il n'est pas nécessaire de se plonger dans sa couche inférieure pour comprendre les détails d'implémentation. Après tout, dans le développement réel, sans Facade, cela n'affecte pas l'utilisation de Laravel. cadre du tout. De plus, en codage réel, il est très simple de personnaliser une Facade. Il suffit d'hériter de la classe de base Facade encapsulée par laravel :

<?php
namespace ThirdProviders\CasServer\Facades;
use Illuminate\Support\Facades\Facade;
use ThirdProviders\CasServer\CasServerManager;
class CasServer extends Facade
{
    protected static function getFacadeAccessor()
    {
        return CasServerManager::class;
    }
}

Implémentez la méthode getFacadeAccessor de la classe de base Facade, et le framework laravel saura quelle instance de service cette Facade. la classe doit être associée à. En fait, le nom renvoyé par cette méthode getFacadeAccess est le nom de liaison de service qui sera introduit ultérieurement. Dans le conteneur Laravel, une instance de service aura un nom de liaison fixe et l'instance pourra être trouvée via ce nom. Alors pourquoi la classe Facade doit-elle uniquement renvoyer le nom de liaison de service ?

On peut regarder le code de la classe App Facade :

<?php
namespace Illuminate\Support\Facades;
/**
 * @see \Illuminate\Foundation\Application
 */
class App extends Facade
{
    /**
     * Get the registered name of the component.
     *
     * @return string
     */
    protected static function getFacadeAccessor()
    {
        return &#39;app&#39;;
    }
}

Son getFacadeAccessor renvoie une chaîne "app", qui est le nom utilisé par le conteneur laravel pour se lier.

Deuxième point : à partir du code source de l'App Facade au point précédent, nous pouvons voir que le nom complet de la classe de l'App Facade est en fait : IlluminateSupportFacadesApp, alors pourquoi pouvons-nous y accéder directement via le nom court de l'App dans le code ? :

<?php
Route::get(&#39;/&#39;, function () {
    dd(App::basePath());
    return &#39;&#39;;
});

Vous voyez que le code ci-dessus n'utilise pas de méthode pleinement qualifiée pour utiliser IlluminateSupportFacadesApp. En fait, App est complètement équivalent à IlluminateSupportFacadesApp, sauf qu'App est beaucoup plus court qu'IlluminateSupportFacadesApp et ne nécessite pas d'utilisation, il est donc pratique à utiliser. Alors, comment est-il implémenté ? Ceci est lié aux alias configurés dans le conteneur laravel. Dans config/app.php, il y a une section d'alias dédiée à la configuration de certains types d'alias :

'aliases' => [
    'App' => Illuminate\Support\Facades\App::class,
    'Artisan' => Illuminate\Support\Facades\Artisan::class,
    'Auth' => Illuminate\Support\Facades\Auth::class,
    'Blade' => Illuminate\Support\Facades\Blade::class,
    'Bus' => Illuminate\Support\Facades\Bus::class,
    'Cache' => Illuminate\Support\Facades\Cache::class,
    'Config' => Illuminate\Support\Facades\Config::class,
    'Cookie' => Illuminate\Support\Facades\Cookie::class,
    'Crypt' => Illuminate\Support\Facades\Crypt::class,
    'DB' => Illuminate\Support\Facades\DB::class,
    'Eloquent' => Illuminate\Database\Eloquent\Model::class,
    'Event' => Illuminate\Support\Facades\Event::class,
    'File' => Illuminate\Support\Facades\File::class,
    'Gate' => Illuminate\Support\Facades\Gate::class,
    'Hash' => Illuminate\Support\Facades\Hash::class,
    'Lang' => Illuminate\Support\Facades\Lang::class,
    'Log' => Illuminate\Support\Facades\Log::class,
    'Mail' => Illuminate\Support\Facades\Mail::class,
    'Notification' => Illuminate\Support\Facades\Notification::class,
    'Password' => Illuminate\Support\Facades\Password::class,
    'Queue' => Illuminate\Support\Facades\Queue::class,
    'Redirect' => Illuminate\Support\Facades\Redirect::class,
    'Redis' => Illuminate\Support\Facades\Redis::class,
    'Request' => Illuminate\Support\Facades\Request::class,
    'Response' => Illuminate\Support\Facades\Response::class,
    'Route' => Illuminate\Support\Facades\Route::class,
    'Schema' => Illuminate\Support\Facades\Schema::class,
    'Session' => Illuminate\Support\Facades\Session::class,
    'Storage' => Illuminate\Support\Facades\Storage::class,
    'URL' => Illuminate\Support\Facades\URL::class,
    'Validator' => Illuminate\Support\Facades\Validator::class,
    'View' => Illuminate\Support\Facades\View::class
],

Puis lors du processus de traitement des requêtes du framework laravel, la classe IlluminateFoundationBootstrapRegisterFacades sera transmis Enregistrons ces alias dans l'environnement global :

<?php
namespace Illuminate\Foundation\Bootstrap;
use Illuminate\Support\Facades\Facade;
use Illuminate\Foundation\AliasLoader;
use Illuminate\Contracts\Foundation\Application;
class RegisterFacades
{
    /**
     * Bootstrap the given application.
     *
     * @param  \Illuminate\Contracts\Foundation\Application  $app
     * @return void
     */
    public function bootstrap(Application $app)
    {
        Facade::clearResolvedInstances();
        Facade::setFacadeApplication($app);
        AliasLoader::getInstance($app->make(&#39;config&#39;)->get(&#39;app.aliases&#39;, []))->register();
    }
}

Nous pouvons donc utiliser directement des alias au lieu du nom de type complet pour effectuer la même fonction d'accès. Si vous avez écrit vous-même des classes avec des noms très longs et que vous les utilisez beaucoup dans le code, vous pouvez également envisager de les configurer dans l'alias config/app.php, et Laravel les enregistrera pour nous.

3) Une autre façon d'obtenir l'instance de conteneur Laravel est d'utiliser $this->app directement dans le fournisseur de services

Le fournisseur de services sera présenté plus tard, mais il vient tout juste d'être introduit maintenant. Étant donné que les classes du fournisseur de services sont instanciées par le conteneur Laravel, ces classes héritent d'IlluminateSupportServiceProvider, qui définit un attribut d'instance $app

🎜🎜Lorsque Laravel instancie le fournisseur de services, il injectera l'instance du conteneur Laravel Allez dans ce $app. Ainsi, chez le fournisseur de services, nous pouvons toujours accéder à l'instance de conteneur Laravel via $this->$app, sans utiliser la fonction app() ou App Facade. 🎜

Pour plus d'articles techniques sur Laravel, veuillez visiter la colonne tutoriel laravel !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!