本文实例讲述了thinkPHP5.0框架应用请求生命周期。分享给大家供大家参考,具体如下:
本篇内容我们对ThinkPHP5.0的应用请求的生命周期做大致的介绍,以便于开发者了解整个执行流程。
1、入口文件
用户发起的请求都会经过应用的入口文件,通常是 public/index.php文件。当然,你也可以更改或者增加新的入口文件。
通常入口文件的代码都比较简单,一个普通的入口文件代码如下:
// 应用入口文件 // 定义项目路径 define('APP_PATH', __DIR__ . '/../application/'); // 加载框架引导文件 require __DIR__ . '/../thinkphp/start.php';
一般入口文件已定义一些常量为主,支持的常量请参考后续的内容或者附录部分。
通常,我们不建议在应用入口文件中加入过多的代码,尤其是和业务逻辑相关的代码。
2、引导文件
接下来就是执行框架的引导文件,start.php文件就是系统默认的一个引导文件。在引导文件中,会依次执行下面操作:
① 加载系统常量定义;
② 加载环境变量定义文件;
③ 注册自动加载机制;
④ 注册错误和异常处理机制;
⑤ 加载惯例配置文件;
⑥ 执行应用;
如果在你的应用入口文件中更改了默认的引导文件,则上述执行流程可能会跟随发生变化。
3、注册自动加载
系统会调用Loader::register()方法注册自动加载,在这一步完成后,所有符合规范的类库(包括Composer依赖加载的第三方类库)都将自动加载。
系统的自动加载由两个部分组成:
① 注册系统的自动加载方法 \think\Loader::autoload
② 注册系统命名空间定义
③ 加载类库映射文件(如果存在)
④ 如果存在Composer安装,则注册Composer自动加载
⑤ 注册Extend扩展目录
一个类库的自动加载检测顺序为:
① 是否定义类库映射;
② PSR-4自动加载检测;
③ PSR-0自动加载检测;
可以看到,定义类库映射的方式是最高效的。
4、注册错误和异常机制
执行Error::register()注册错误和异常处理机制。
由三部分组成:
① 应用关闭方法:think\Error::appShutdown
② 错误处理方法:think\Error::appError
③ 异常处理方法:think\Error::appException
注册应用关闭方法是为了便于拦截一些系统错误。
在整个应用请求的生命周期过程中,如果抛出了异常或者严重错误,均会导致应用提前结束,并响应输出异常和错误信息。
5、应用初始化
执行应用的第一步操作就是对应用进行初始化,包括:
加载应用(公共)配置;
加载应用状态配置;
加载别名定义;
加载行为定义;
加载公共(函数)文件;
加载扩展配置文件(由extra_config_list定义);
加载扩展函数文件(由extra_file_list定义);
设置默认时区;
加载系统语言包;
6、URL访问检测
应用初始化完成后,就会进行URL的访问检测,包括PATH_INFO检测和URL后缀检测。
5.0的URL访问必须是PATH_INFO方式(包括兼容方式)的URL地址,例如:
http://serverName/index.php/index/index/hello/val/value
所以,如果你的环境只能支持普通方式的URL参数访问,那么必须使用
http://serverName/index.php?s=/index/index/hello&val=value
如果是命令行下面访问入口文件的话,则通过
$php index.php index/index/hello/val/value...
获取到正常的$_SERVER['PATH_INFO']
参数后才能继续。
7、路由检测
如果开启了url_route_on参数的话,会首先进行URL的路由检测。
如果一旦检测到匹配的路由,根据定义的路由地址会注册到相应的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、应用结束
事实上,在应用的数据响应输出之后,应用并没真正的结束,系统会在应用输出或者中断后进行日志保存写入操作。
系统的日志包括用户调试输出的和系统自动生成的日志,统一会在应用结束的时候进行写入操作。
而日志的写入操作受日志初始化的影响。
希望本文所述对大家基于ThinkPHP框架的PHP程序设计有所帮助。
thinkPHP5.0框架应用请求生命周期分析
- Author -
chinalorin声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。
Reply on: @reply_date@
@reply_contents@