The core concept of Laravel

工欲善其事, its prerequisite. In the process of developing xblog, a little bit of laravel thought was realized. Indeed, after reading this article you may not be able to write a blog from scratch, but after you know the core concept of laravel, when you write Laravel again, you will become clear and confident. life cycle of PHP

Everything has his life cycle. Students familiar with Android must be familiar with the life cycle of Android's most classic activity, and Laravel is no exception, and Laravel apps have its own lifecycle. What Laravel is. A PHP framework. So in order to really say the life cycle of laravel, you must be clear about the life cycle of PHP. The original reference here, here to make a summary.
PHP has two modes of operation, Web mode and CLI (command line) mode. When we typed PHP this command in the terminal, we used the CLI mode, and when we used the Nginx or the other Web server as the host to process a incoming request, PHP was invoked and the Web mode was used. When we request a PHP file, such as Laravel's public\index.php file, PHP in order to complete this request, there will be 5 stages of life cycle switching: module initialization (Minit), That is, the extended initialization function specified in php.ini is invoked to initialize the work, such as the MySQL extension. Request initialization (Rinit), a symbol table initialized to the variable name and variable value content required to execute this script, such as the $_session variable. Execute the PHP script. Request processing is complete, calling the Rshutdown method of each module in order, calling the unset function for each variable, such as unset $_session variable (Shutdown). The module Shutdown is closed, and PHP calls each extended Mshutdown method, which is the last chance for each module to release memory. This means that there is no next request.

Web mode is very similar to CLI (command line) mode, the difference is that the CLI pattern will experience a complete 5 cycles per script execution, because your script does not have the next request, and the Web mode may have multiple threads in order to handle concurrency, so life cycles 1 and 5 are likely to execute only once, The next time the request comes, repeat the 2-4 lifecycle, which saves the overhead of system module initialization.

As you can see, the PHP lifecycle is very symmetrical. Said so much, is to locate Laravel run where, yes, laravel just run the third stage:

It's no use knowing that. You can optimize your laravel code to get a deeper understanding of Larave's Singleton (single example). At least you know, every time the request is over, the PHP variable will be unset,laravel singleton just Singleton in the process of a request; static variables in laravel cannot be shared among multiple requests. Because every time the request is over, it will unset. Understanding these concepts is the first and most critical step in writing high-quality code. So remember, PHP is a scripting language, all variables only take effect on this one request, and are reset at the next request, not as a global function of Java static variables.

Well, start laravel life cycle. the life cycle of Laravel Overview

The Laravel life cycle begins at public\index.php and ends with public\index.php.

Note: The following figure arrows represent the request flow

That's a little hasty, but it's true. Below is public\index.php all source code (laravel source annotation is the best laravel document), more specifically can be divided into four steps:

1. Require __dir__. ' /.. /bootstrap/autoload.php ';

2. $app = require_once __dir__. ' /.. /bootstrap/app.php ';
   $kernel = $app->make (illuminate\contracts\http\kernel::class);

3. $response = $kernel->handle (
    $request = Illuminate\http\request::capture ()
   );
   $response->send ();

4. $kernel->terminate ($request, $response);

1 2 3 4 5 6 7 8 9 10 11

The four-step detailed explanation is:

1. Register load composer automatically generated class loader, including all your composer require dependencies (corresponding to code 1).
2. Build the container container,application instance and register the core component (Httpkernel,consolekernel,exceptionhandler) with the container (corresponding to code 2, the container is important, followed by a detailed explanation).
3. Process the request, generate and send a response (corresponding to code 3, it is no exaggeration to say that your 99% code is running in this little handle method).
4. End of request, callback (corresponding to code 4, remember to terminate middleware?) Yes, that's the callback here.

start Laravel Basic services

We may wish to elaborate a little more:
The first step of registering the load composer automatically generated class loader is to load the initialization of a third-party dependency that does not belong to the Laravel core, so far.
The second step is to build the container container and register the core components to the container, which involves the container container and contract contracts, which is the focus of laravel, which will be explained in detail below.
The emphasis is on the third step of processing the request, generating and sending the response.
First, the Laravel framework captures the request sent to the public\index.php by the user, generates Illuminate\http\request instances, and passes it to this small handle method. Within the method, bind the $request instance to the $app container that is generated on the second step. After the request is actually processed, invoke the bootstrap method, perform the necessary loading and registration, such as detecting the environment, loading the configuration, registering the facades (illusion), registering the service provider, starting the service provider, and so on. This is an array of launches, specifically in Illuminate\foundation\http\kernel, including:

protected $bootstrappers = [
    ' illuminate\foundation\bootstrap\detectenvironment ',
    ' illuminate\foundation\ Bootstrap\loadconfiguration ',
    ' illuminate\foundation\bootstrap\configurelogging ', '
    Illuminate\ Foundation\bootstrap\handleexceptions ',
    ' illuminate\foundation\bootstrap\registerfacades ', '
    Illuminate \foundation\bootstrap\registerproviders ',
    ' illuminate\foundation\bootstrap\bootproviders ',
];

1 2 3 4 5 6 7 8 9

Look at the class name, Laravel is in order to traverse the implementation of the registration of these basic services, attention order: Facades before the serviceproviders,facades is also the focus, said later, here a simple mention, registration facades is registered config\ Aliases arrays in app.php, many of the classes you use, such as auth,cache,db, are facades, and the Serviceproviders register method is always executed before the boot method. Avoid the phenomenon that the boot method relies on an instance and the instance is not registered.

So, you can use any facades in the Serviceproviders register method to use an instance or facades registered in any of the register methods in the Serviceproviders boot method, This will never create a phenomenon that relies on a class but is not registered. To pass a request to a route

Note that Laravel has not yet been executed to the main code you wrote (except in serviceproviders) because the request has not been passed to the route.

After the Laravel base service is started, the request is passed to the route. Passing to a route is passed through pipeline (another discourse), but pipeline has a wall that passes through all requests before it is passed to the route, which is defined in the $middleware array in app\http\kernel.php, which is, yes, middleware. , the default is only one Checkformaintenancemode middleware that detects if your site is temporarily closed. This is a global middleware, all requests go through, you can also add your own global middleware.

It then traverses all registered routes, finds the first route to match, passes through its routing middleware, enters the controller or closure function, and executes your specific logical code.

So, before the request arrives at the code you write, Laravel has done a lot of work, and the request has been hardships, and those incompatible or malicious requests have been laravel isolated.
Service Container

A service container is a common container that is used to load instances of a class and then take it out when needed. In more professional terms, the service container implements a control reversal (inversion of controls, abbreviated as IOC), meaning that when class A needs a Class B Normally, we need to go to new Class B, which means we have to know more details about class B, such as constructors, This dependency is devastating as the complexity of the project increases. Inversion of control means that the process of taking class A actively to get Class B is reversed to become passive, and class A only needs to declare what it needs and then provide it by the container.

The advantage of this is that class A does not depend on the implementation of Class B, which solves the coupling problem to some extent.

In the Laravel service container, there are two types of dependency injection (Dependency injection) in order to achieve control reversal. Binding. Dependency Injection

Dependency injection is a type of hint, an example of an official website:

Class Usercontroller extends Controller
{
    /**
     * The user repository implementation.
     *
     * @var userrepository
    /protected $users;

    /**
     * Create a new controller instance.
     * *
     @param  userrepository  $users
     * @return void
     *
    /Public Function __construct ( Userrepository $users)
    {
        $this->users = $users;
    }

    /** * Show the profiles for the
     given user.
     *
     * @param  int  $id
     * @return Response
     *
    /Public Function Show ($id)
    {
        $user = $this->users->find ($id);

        Return view (' User.profile ', [' User ' => $user]);
    }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

Here Usercontroller needs a userrepository instance, we simply declare the type we need in the constructor, and the container automatically generates an instance of userrepository (or implementation class, when instantiating Usercontroller). Because Userrepository can be an interface, instead of taking the initiative to get an instance of userrepository, it avoids more details about userrepository, and does not need to address the dependencies that userrepository produces, What we do is simply declare the type we need, and all the dependencies are addressed to the container. (Xblog uses the repository is the design pattern, you can refer to) binding

Binding operations are generally in the Register method in Serviceproviders, the most basic binding is the bind method of the container, which accepts the alias of a class or the full name and a closure to obtain an instance:

$this->