Laravel framework in addition to providing some basic functions (such as controller, view, model), there are middleware, facade, contract and so on, how these things are used in laravel framework? I’ll talk about it with you today.

First, you should understand the architectural pattern of the Laravel framework (the design core, The Laravel framework is developed using the development pattern of service componentalization, the Laravel framework is composed of different service components). Laravel components are composed of multiple service providers in Laravel. Hierarchical design: Put libraries with the same functionality in the same folder. The Laravel framework has multiple classes that make up services, and multiple services that make up components. Laravel uses a componentized development model where multiple classes -> services -> components make up services and services make up components.

Multiple components provide different services, and then multiple services make up our project.

Request life cycle

The general process is shown as follows:

Theoretically, there are many phases of the life cycle, but most developers only need to focus on routing, middleware, controllers, closure functions, logic processing, and so on

Of course, inside each step, there will be more detailed execution process. Generally, there is no in-depth study of the framework or transformation of the framework, rarely detailed research, but studying the bottom layer is still a good choice for learning.

Services are about providing you with what you need, and laravel provides authentication services, database services, caching services, queue services, and so on. All laravel framework services are defined in app/config/app.php

Service providers can offer you a set of services is a service provider, laravel as shown above is actually defined inside the server providers, such as IlluminateAuthAuthServiceProvider: : class, provides certification services the service provider. IlluminateCacheCacheServiceProvider: : class, provide service provider of the benefits of caching service: developers can save more energy to handle program logic, and different development between individuals can reach a certain tacit understanding, one of the most important is that project layer decoupling, The business logic depends only on the service, not on the underlying implementation of the service. After decoupling, we can upgrade or customize the underlying implementation of the service at will, as long as we ensure that the underlying class implements the service summary: In fact, the service is an abstract concept, and the server provider is the concrete implementor of this abstract concept

Service container Put all the services in a box, the service container. The service container inside Laravel is located

vendor/laravel/frameworksrcilluminateContainerContainer.php
Copy the code

Container.php is the service Container for the Laravel framework.

Contracts are used to plan the format, methods, parameters, etc., of service providers, and they impose certain constraints on them. So all contracts within the framework are interfaces that regulate service providers.

Facade Facade once again shows Laravel’s design excellence, it makes Laravel more flexible and scalable, so its concept is: 1 provides static proxies for the services in the service container for developers. 2 It complements the way services are accessed. Before using a service, you must obtain an instance of the service and then invoke the methods of the service. 3 In config/app.php, most service aliases use facades. 4 It is risky to use facades, not as many as possible. This is described in the manual, but the details need to be found in development

Laravel framework architecture diagram

The Laravel framework is made up of multiple service components -> service providers (the different service components at the bottom). The Foundation Application is used to create the service provider, which is stored in the service Container of the Container and managed by the Container. The Application inherits the Container. To agree on the services provided by service providers, we define a specification, which is called a contract. For our users (the top user) who want to use the Laravel framework, they must use it through the Controller (the Controller above). Using the Laravel framework, they mainly use the service provider in Laravel (the new service above), which is the most traditional development mode. There is no direct relationship to the server container, and if laravel is designed this way, it is basically the same as any other framework without any advantage. So you don’t do that much. Since there is a contract, the contract is the interface of the service provider, we can also use the contract directly, the yellow line next to the new service. The downside of using contract injection is that if multiple contracts are used in a method, we have to inject multiple contracts, which makes the code look unelegant. In Laravel comes a facade that allows us to elegantly invoke the server provider’s classes. Because each service provider’s class is too long, for example:

IlluminateCookieCookieServiceProvider::class,
IlluminateDatabaseDatabaseServiceProvider::class,
Copy the code

So we introduce aliases, which simplify the class of the service provider we call. Events: Events in the laravel model, such as a listener when a user is operating on a database. Monitor the entire project run. Similar to the hooks and behavior in TP5. Middleware: do user requests to do certain filtering.