This article is written by the tutorial column of laravel to introduce how to obtain the container instance in the code. I hope it will be helpful to friends in need!
The laravel container instance is unique throughout the request life cycle and manages all service component instances. So what are the ways to get an instance of the laravel container? The following methods are commonly used:
1) Through the help function of app:
$app = app();
The auxiliary function of app is defined in
In the file, this file defines many help functions and will be automatically loaded into the project through composer. Therefore, the functions can be accessed from any code location involved in http request processing, such as app().
2) Through the App Facade
<?php Route::get('/', function () { dd(App::basePath()); return ''; });
The way to get the container instance through the App Facade is different from the above. You cannot assign the App to a variable first and then call the container through the variable. Methods. This is because App is just a class name, and we cannot copy a class name into a variable. $app = App; is not a legal executable statement, but $app = app(); is a legal executable statement, because it is followed by app(), which represents a function call. App::basePath(); is also a legal statement, it is calling the static method of the class.
Add two more points:
The first point: Facade is a special feature in the laravel framework. Each Facade will be associated with an instance object in the container. We can directly pass the Facade A class static method call is used to invoke methods on its associated instance object. For example, the Facade of App, when calling App::basePath(), is actually equivalent to app()->basePath().
This underlying mechanism also depends on the characteristics of the PHP language. It needs to set a static member in each Facade and associate it with an instance object of the service. When calling the static method of the Facade class , parse out the called method name, then call the method of the same name of the associated service instance, and finally return the result.
I think it is enough to understand what role Facade can play. It is not necessary to delve into its bottom layer to understand the implementation details. After all, in actual development, Facade is not used and it does not affect the use of the laravel framework at all. . In addition, in actual coding, it is very easy to customize a Facade. Just inherit the Facade base class encapsulated by 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; } }
Implement the getFacadeAccessor method of the Facade base class, and the laravel framework will know what this Facade class should be like Which service instance is associated. In fact, the name returned by this getFacadeAccess method is the service binding name to be introduced later. In the laravel container, a service instance will have a fixed binding name, and the instance can be found through this name. So why the Facade class only needs to return the service binding name.
We can look at the code of the App Facade class:
<?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 'app'; } }
Its getFacadeAccessor returns a string "app", which is the name used by the laravel container to bind itself. .
Second point: From the source code of the App Facade in the previous point, we can see that the full class name of the App Facade is actually: Illuminate\Support\Facades\App, so why can we pass it directly in the code? App can be accessed by the short name:
<?php Route::get('/', function () { dd(App::basePath()); return ''; });
You see that the above code does not use use or fully qualified way to use Illuminate\Support\Facades\App. In fact, App is completely equivalent to Illuminate\Support\Facades\App, except that App is much shorter than Illuminate\Support\Facades\App and does not require use, so it is convenient to use. So how is it implemented? This is related to the alias configured in the laravel container. In config/app.php,
has a section of aliases specifically used to configure some types of aliases:
'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 ],
Then the request is processed in the laravel framework During the process, these aliases will be registered into the global environment through the Illuminate\Foundation\Bootstrap\RegisterFacades class:
<?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('config')->get('app.aliases', []))->register(); } }
So we can directly use aliases instead of the complete type name to perform the same access function. If you have written some classes yourself with long names and are used a lot in the code, you can also consider configuring them in the config/app.php alias, and laravel will register them for us.
3) Another way to get the laravel container instance is to use $this->app
directly in the service provider. The service provider will be introduced later, but it is just introduced now. Because service provider classes are instantiated by the laravel container, these classes inherit from Illuminate\Support\ServiceProvider, which defines an instance attribute $app
laravel in When instantiating the service provider, the laravel container instance will be injected into the $app. So in the service provider, we can always access the laravel container instance through $this->$app, without using the app() function or App Facade.
For more laravel technical articles, please visit the laravel tutorial column!
The above is the detailed content of Get the container instance in the code (Laravel). For more information, please follow other related articles on the PHP Chinese website!

Laravel stands out by simplifying the web development process and delivering powerful features. Its advantages include: 1) concise syntax and powerful ORM system, 2) efficient routing and authentication system, 3) rich third-party library support, allowing developers to focus on writing elegant code and improve development efficiency.

Laravelispredominantlyabackendframework,designedforserver-sidelogic,databasemanagement,andAPIdevelopment,thoughitalsosupportsfrontenddevelopmentwithBladetemplates.

Laravel and Python have their own advantages and disadvantages in terms of performance and scalability. Laravel improves performance through asynchronous processing and queueing systems, but due to PHP limitations, there may be bottlenecks when high concurrency is present; Python performs well with the asynchronous framework and a powerful library ecosystem, but is affected by GIL in a multi-threaded environment.

Laravel is suitable for projects that teams are familiar with PHP and require rich features, while Python frameworks depend on project requirements. 1.Laravel provides elegant syntax and rich features, suitable for projects that require rapid development and flexibility. 2. Django is suitable for complex applications because of its "battery inclusion" concept. 3.Flask is suitable for fast prototypes and small projects, providing great flexibility.

Laravel can be used for front-end development. 1) Use the Blade template engine to generate HTML. 2) Integrate Vite to manage front-end resources. 3) Build SPA, PWA or static website. 4) Combine routing, middleware and EloquentORM to create a complete web application.

PHP and Laravel can be used to build efficient server-side applications. 1.PHP is an open source scripting language suitable for web development. 2.Laravel provides routing, controller, EloquentORM, Blade template engine and other functions to simplify development. 3. Improve application performance and security through caching, code optimization and security measures. 4. Test and deployment strategies to ensure stable operation of applications.

Laravel and Python have their own advantages and disadvantages in terms of learning curve and ease of use. Laravel is suitable for rapid development of web applications. The learning curve is relatively flat, but it takes time to master advanced functions. Python's grammar is concise and the learning curve is flat, but dynamic type systems need to be cautious.

Laravel's advantages in back-end development include: 1) elegant syntax and EloquentORM simplify the development process; 2) rich ecosystem and active community support; 3) improved development efficiency and code quality. Laravel's design allows developers to develop more efficiently and improve code quality through its powerful features and tools.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software

VSCode Windows 64-bit Download
A free and powerful IDE editor launched by Microsoft

SublimeText3 Mac version
God-level code editing software (SublimeText3)

SAP NetWeaver Server Adapter for Eclipse
Integrate Eclipse with SAP NetWeaver application server.

Dreamweaver Mac version
Visual web development tools