Detailed overview of the overall architecture of thinkPHP5.0 framework

This article mainly introduces the overall architecture of thinkPHP5.0 framework, and briefly introduces the applications, modules, MVC, drivers, behaviors, namespaces of thinkPHP5.0 and other concepts and basic usage, friends in need can refer to

This article describes the overall architecture of thinkPHP5.0 framework. Share it with everyone for your reference, the details are as follows:

ThinkPHP5.0 application is based on MVC (Model-View-Controller) Come organize.

MVC is a design pattern that enforces separation of application input, processing, and output. Applications using MVC are divided into three core components: model (M), view (V), and controller (C), each of which handles its own tasks.

5.0’s URL access is determined by routing. If routing is turned off or there is no matching route, it is based on:

serverName/index .php (or other application entry files)/module/controller/operation/parameter/value...

It is necessary to understand some of the following concepts, maybe in It will be mentioned frequently in the following content.

Entry file

The PHP file requested by the user, responsible for processing the life cycle of a request (note, not necessarily a URL request), and the final The common entry file is index.php. Sometimes new entry files are added for some special needs, such as a separate entry file for the background module admin.phpOr a controller program entrythink all belong to the entry file.

Application

Application in ThinkPHP is a object that manages the system architecture and life cycle. It is controlled by the system's \think\App Class completion, applications are usually called and executed in entry files. We consider applications with the same application directory (APP_PATH) to be the same application, but one application may have multiple entry files.

The application has its own independent configuration file and public (function) file.

Module

A typical application is composed of multiple modules. These modules are usually a subdirectory under the application directory. Each module is independent of itself. Configuration files, public files and class library files.

5.0 supports single module architecture design. If there is only one module under your application, then the subdirectory of this module can be omitted and modified in the application configuration file :

'app_multi_module' =>  false,

Controller

Each module has an independent MVC class library and configuration file. There are multiple controllers under a module responsible for responding to requests, and each controller is actually an independent controller class.

The controller is mainly responsible for receiving requests, calling related model processing, and finally outputting it through the view. Strictly speaking, the controller should not be too involved in business logic processing.

In fact, the controller can be skipped in 5.0. Through routing, we can directly dispatch the request to a certain model or other class for processing.

5.0's controller class is more flexible and can be used without inheriting any basic class library.

A typical Index controller class is as follows:

namespace app\index\controller;
class Index 
{
  public function index()
  {
    return 'hello,thinkphp!';
  }
}

Operation

A controller contains multiple operations (methods), and the operation method is one The smallest unit of URL access.

The following is a typical Index controller operation method definition, which contains two operation methods:

namespace app\index\controller;
class Index 
{
  public function index()
  {
    return 'index';
  }
  public function hello($name)
  {
    return 'Hello,'.$name;
  }
}

The operation method can not use any parameters. If a non-optional parameter is defined, This parameter must be passed in through the user request. If it is a URL request, it is usually passed in through $_GET or $_POST.

Model

Model classUsually completes the actual business logic and data encapsulation, and returns format-independent data.

The model class does not necessarily need to access the database, and in the 5.0 architecture design, the database connection will only be made when the actual database query operation is performed. Yes A true lazy connection.

ThinkPHP的模型层支持多层设计，你可以对模型层进行更细化的设计和分工，例如把模型层分为逻辑层/服务层/事件层等等。

视图

控制器调用模型类后返回的数据通过视图组装成不同格式的输出。视图根据不同的需求，来决定调用模板引擎进行内容解析后输出还是直接输出。

视图通常会有一系列的模板文件对应不同的控制器和操作方法，并且支持动态设置模板目录。

驱动

系统很多的组件都采用驱动式设计，从而可以更灵活的扩展，驱动类的位置默认是放入核心类库目录下面，也可以重新定义驱动类库的命名空间而改变驱动的文件位置。

行为

行为（Behavior）是在预先定义好的一个应用位置执行的一些操作。类似于AOP编程中的“切面”的概念，给某一个切面绑定相关行为就成了一种类AOP编程的思想。所以，行为通常是和某个位置相关，行为的执行时间依赖于绑定到了哪个位置上。

要执行行为，首先要在应用程序中进行行为侦听，例如：

// 在app_init位置侦听行为
\think\Hook::listen('app_init');

然后对某个位置进行行为绑定：

// 绑定行为到app_init位置
\think\Hook::add('app_init','\app\index\behavior\Test');

一个位置上如果绑定了多个行为的，按照绑定的顺序依次执行，除非遇到中断。

命名空间

ThinkPHP5采用了PHP的命名空间进行类库文件的设计和规划，并且符合PSR-4的自动加载规范。

The above is the detailed content of Detailed overview of the overall architecture of thinkPHP5.0 framework. For more information, please follow other related articles on the PHP Chinese website!