


A brief introduction to service providers and facade patterns in Laravel
This article mainly introduces you to the relevant information about the use of service providers and facade patterns in Laravel. The article introduces you to the service providers and facade patterns in Laravel through detailed example codes. It will be helpful for your study or The work has certain reference and learning value. Friends who need it can study together.
Preface
In laravel, when we may need to use the classes we added, we can create a folder specifically to store class files. You can also use Laravel's service provider.
In fact, there is not much difference between the two. The main reason is that if the former is used, it will depend on the business code. Imagine if a controller references many custom class files, then you can imagine what will happen. How many dependencies are generated, so we can use the service provider method to register classes in the laravel container. In this case, dependencies can be managed in a separate configuration file, and logic and later maintenance will be much more convenient.
Using facades is mainly because you don’t need to instantiate a class. You can use static methods to access class methods, which is more convenient to use. However, this actually has disadvantages, such as not being able to jump directly to the corresponding Inside the method, it is not possible to intuitively understand the usage of this method. Personal development may not have much impact, but if it is developed by a team, it may be a bit dizzying to use it.
Taking the file system that comes with Laravel as an example, a service provider is registered in the providers array of the configuration file in config/app.php:
Illuminate\Filesystem\FilesystemServiceProvider::class,
A facade is defined in the alias array:
‘File' => Illuminate\Support\Facades\File::class,
Through these two steps, we can use Laravel very conveniently File system related operations, and the calling form is very simple, such as:
File::exist($path)
to determine whether the file exists.File::get($path, $lock = false)
, get the contents of a file.File::append($path, $data)
, append the content to the end of a file.File::files($directory)
, get all the files in a directory.
So how is this done? Let’s talk about Laravel’s service provider and facade mode respectively.
Service provider
Let’s take a look at the definition first:
The service provider is the center where all Laravel applications are started. . All core Laravel services, including your own applications, are started through service providers.
In the file system service provider, located at /vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemServiceProvider.php, the register method can see that a singleton is bound:
protected function registerNativeFilesystem() { $this->app->singleton('files', function () { return new Filesystem; }); }
This singleton is the singleton mode of the Filesystem class. Of course, this service provider can also bind other singletons or do more things. We only study the principle of File::exist()
here.
So there is a single instance of files, which is actually an instance of the Filesystem class.
At this time, if there is no Facade, you can also call the method of the Filesystem instance, that is, call it like this:
app(‘files')->exist($path)
Okay , now let’s talk about Facade.
Facade facade mode
Let’s take a look at the introduction first:
Facades /fəˈsäd/ is the application The classes available in the application's service container provide a "static" interface. Laravel comes with many facades that can be used to access almost all of its services. Laravel facades are "static proxies" for base classes in the service container. Compared with traditional static method calls, facades provide a simpler and richer syntax, while also having better testability and scalability.
At the beginning of this article, we mentioned that the alias array defines a File. The specific class is
Illuminate\Support\Facades\File::class,
Its content is:
class File extends Facade { /** * Get the registered name of the component. * * @return string */ protected static function getFacadeAccessor() { return 'files'; } }
It actually returns a name. Note that the name files is the name of the singleton mode just bound? That's right.
In this way, you can use the File alias or facade to call methods in this Filesystem instance.
Through this article, I hope everyone can understand the relationship between service providers, Facade, and instances of the actually called classes.
The above is the entire content of this article. I hope it will be helpful to everyone's study. For more related content, please pay attention to the PHP Chinese website!
Related recommendations:
PHP Observer Pattern in Laravel Framework
The above is the detailed content of A brief introduction to service providers and facade patterns in Laravel. For more information, please follow other related articles on the PHP Chinese website!

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

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

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

Hot Topics



The latest versions of Laravel 9 and CodeIgniter 4 provide updated features and improvements. Laravel9 adopts MVC architecture and provides functions such as database migration, authentication and template engine. CodeIgniter4 uses HMVC architecture to provide routing, ORM and caching. In terms of performance, Laravel9's service provider-based design pattern and CodeIgniter4's lightweight framework give it excellent performance. In practical applications, Laravel9 is suitable for complex projects that require flexibility and powerful functions, while CodeIgniter4 is suitable for rapid development and small applications.

Compare the data processing capabilities of Laravel and CodeIgniter: ORM: Laravel uses EloquentORM, which provides class-object relational mapping, while CodeIgniter uses ActiveRecord to represent the database model as a subclass of PHP classes. Query builder: Laravel has a flexible chained query API, while CodeIgniter’s query builder is simpler and array-based. Data validation: Laravel provides a Validator class that supports custom validation rules, while CodeIgniter has less built-in validation functions and requires manual coding of custom rules. Practical case: User registration example shows Lar

For beginners, CodeIgniter has a gentler learning curve and fewer features, but covers basic needs. Laravel offers a wider feature set but has a slightly steeper learning curve. In terms of performance, both Laravel and CodeIgniter perform well. Laravel has more extensive documentation and active community support, while CodeIgniter is simpler, lightweight, and has strong security features. In the practical case of building a blogging application, Laravel's EloquentORM simplifies data manipulation, while CodeIgniter requires more manual configuration.

Laravel - Artisan Commands - Laravel 5.7 comes with new way of treating and testing new commands. It includes a new feature of testing artisan commands and the demonstration is mentioned below ?

When choosing a framework for large projects, Laravel and CodeIgniter each have their own advantages. Laravel is designed for enterprise-level applications, offering modular design, dependency injection, and a powerful feature set. CodeIgniter is a lightweight framework more suitable for small to medium-sized projects, emphasizing speed and ease of use. For large projects with complex requirements and a large number of users, Laravel's power and scalability are more suitable. For simple projects or situations with limited resources, CodeIgniter's lightweight and rapid development capabilities are more ideal.

For small projects, Laravel is suitable for larger projects that require strong functionality and security. CodeIgniter is suitable for very small projects that require lightweight and ease of use.

Comparing Laravel's Blade and CodeIgniter's Twig template engine, choose based on project needs and personal preferences: Blade is based on MVC syntax, which encourages good code organization and template inheritance. Twig is a third-party library that provides flexible syntax, powerful filters, extended support, and security sandboxing.

Laravel - Artisan Console - Laravel framework provides three primary tools for interaction through command-line namely: Artisan, Ticker and REPL. This chapter explains about Artisan in detail.
