Detailed analysis of the request life cycle of thinkPHP5.0 framework application implementation

This article mainly introduces thinkPHP5.0 framework application requestlife cycle, and analyzes in detail the various execution processes involved in the thinkPHP5.0 framework application request life cycle. Friends in need can refer to

The examples in this article describe the thinkPHP5.0 framework application request life cycle. Share it with everyone for your reference, the details are as follows:

In this article, we give a general introduction to the life cycle of application requests in ThinkPHP5.0, so that developers can understand the entire execution process.

1, Entry file

Requests initiated by users will go through the application’s entry file, usually the public/index.php file. Of course, you can also change or add new entry files.

Usually the code of the entry file is relatively simple. A common entry file code is as follows:

// 应用入口文件
// 定义项目路径
define('APP_PATH', DIR . '/../application/');
// 加载框架引导文件
require DIR . '/../thinkphp/start.php';

General entry files have defined some constantsmainly. Please refer to the supported constants. Refer to the following content or appendix.

Generally, we do not recommend adding too much code to the application entry file, especially code related to business logic.

2. Boot file

The next step is the boot file for the execution framework. The start.php file is the default boot file of the system. In the boot file, the following operations will be performed in sequence:

① Load system constant definitions;
② Load environment variable definition files;
③ Register the automatic loading mechanism;
④ Register Error and exception handling mechanism;
⑤ Load the conventional configuration file;
⑥ Execute the application;

If the default boot file is changed in your application entry file, the above execution process Changes may follow.

3. Register for automatic loading

The system will call the Loader::register() method to register for automatic loading. After this step is completed, all that comply with the specification Class libraries (including third-party class libraries that Composer depends on loading) will be loaded automatically.

The automatic loading of the system consists of two parts:

① The automatic loading method of the registration system \think\Loader::autoload
② The registration system namespace Definition
③ Load the class library mapping file (if it exists)
④ If there is a Composer installation, register Composer for automatic loading
⑤ Register the Extend extension directory

A class The order of automatic loading detection of libraries is:

① Whether to define class library mapping;
② PSR-4 automatic loading detection;
③ PSR-0 automatic loading detection;

It can be seen that the way of defining class library mapping is the most efficient.

4. Register error and exception mechanism

Execute Error::register() to register error and exception handling mechanism.

consists of three parts:

① Application shutdown method: think\Error::appShutdown<br/>② Error handlingMethod: think\Error::appError<br/>③Exception handling method: think\Error::appException

Registering the application shutdown method is to facilitate interception of some system errors.

During the entire application request life cycle, if an exception or serious error is thrown, it will cause the application to end early and respond by outputting exceptions and error messages.

5. Application initialization

The first step to execute an application is to initialize the application, including:

Load the application (public ) configuration;
Load application state configuration;
Load alias definition;
Load behavior definition;
Load public (function) file;
Load extended configuration file (defined by extra_config_list);
Load the extension function file (defined by extra_file_list);
Set the default time zone;
Load the system language package;

6, URL accessDetection

After the application initialization is completed, URL access detection will be performed, including PATH_INFO detection and URL suffix detection.

5.0 URL access must be a URL address in PATH_INFO mode (including compatible mode), for example:

serverName/index.php/index/index/hello/val/value

So, if your environment can only support normal URL parameter access, you must use

serverName/index.php?s=/index/index/hello&val =value

If you access the entry file from the command line, use

$php index.php index/index/hello/val/value...

Can continue only after obtaining the normal $_SERVER['PATH_INFO'] parameters.

7. Route detection

If the url_route_on parameter is enabled, URL route detection will be performed first.

如果一旦检测到匹配的路由，根据定义的路由地址会注册到相应的URL调度。

5.0的路由地址支持如下方式：

路由到模块/控制器/操作；
路由到外部重定向地址；
路由到控制器方法；
路由到闭包函数；
路由到类的方法；

路由地址可能会受域名绑定的影响。

如果关闭路由或者路由检测无效则进行默认的模块/控制器/操作的分析识别。

如果在应用初始化的时候指定了应用调度方式，那么路由检测是可选的。

可以使用 \think\App::dispatch() 进行应用调度。

8、分发请求

在完成了URL检测和路由检测之后，路由器会分发请求到对应的路由地址，这也是应用请求的生命周期中最重要的一个环节。

在这一步骤中，完成应用的业务逻辑及数据返回。

建议统一使用return返回数据，而不是echo输出，如非必要，请不要执行exit中断。

直接echo输出的数据将无法进行自动转换响应输出的便利。

下面是系统支持的分发请求机制，可以根据情况选择：

模块/控制器/操作

这是默认的分发请求机制，系统会根据URL或者路由地址来判断当前请求的模块、控制器和操作名，并自动调用相应的访问控制器类，执行操作对应的方法。

该机制下面，首先会判断当前模块，并进行模块的初始化操作（和应用的初始化操作类似），模块的配置参数会覆盖应用的尚未生效的配置参数。

支持模块映射、URL参数绑定到方法，以及操作绑定到类等一些功能。

控制器方法

和前一种方式类似，只是无需判断模块、控制器和操作，直接分发请求到一个指定的控制器类的方法，因此没有进行模块的初始化操作。

外部重定向

可以直接分发请求到一个外部的重定向地址，支持指定重定向代码，默认为301重定向。

闭包函数

路由地址定义的时候可以直接采用闭包函数，完成一些相对简单的逻辑操作和输出。

类的方法

除了以上方式外，还支持分发请求到类的方法，包括：
静态方法：

'blog/:id'=>'\org\util\Blog::read'

类的方法：

'blog/:id'=>'\app\index\controller\Blog@read'

9、响应输出

控制器的所有操作方法都是return返回而不是直接输出，系统会调用Response::send方法将最终的应用返回的数据输出到页面或者客户端，并自动转换成default_return_type参数配置的格式。所以，应用执行的数据输出只需要返回一个正常的PHP数据即可。

10、应用结束

事实上，在应用的数据响应输出之后，应用并没真正的结束，系统会在应用输出或者中断后进行日志保存写入操作。

系统的日志包括用户调试输出的和系统自动生成的日志，统一会在应用结束的时候进行写入操作。

而日志的写入操作受日志初始化的影响。

The above is the detailed content of Detailed analysis of the request life cycle of thinkPHP5.0 framework application implementation. For more information, please follow other related articles on the PHP Chinese website!