Overview of the overall architecture of thinkPHP5.0 framework [application, module, MVC, driver, behavior, namespace, etc.]

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

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

ThinkPHP5.0 applications are organized based on the MVC (Model-View-Controller) method.

MVC is a design pattern that enforces separation of input, processing, and output of an application. 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 URL access is determined by routing. If routing is turned off or there is no matching route, it is based on:

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

It is necessary to understand some of the following concepts, which may be often mentioned in the following content. and.

Entry file

The PHP file requested by the user is responsible for processing the life cycle of a request (note, not necessarily a URL request). The most common entry file isindex.php, sometimes new entry files are added for some special needs, such as a separate entry file for the background module admin.php or a controller program Entry think all belong to entry files.

Application

Application in ThinkPHP is an object that manages the system architecture and life cycle, and is completed by the system's \think\App class. Applications are usually called and executed in entry files. Applications with the same application directory (APP_PATH) are considered to be the same application, but an 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 one module. Respond 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 does not need to inherit 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 an operation method is the smallest unit of URL access.

The following is a typical Index controller operation method definition, including 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 be omitted For any parameter, if a non-optional parameter is defined, the 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 classes usually complete the actual business logic and data encapsulation, and return data independent of the format.

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, which is a true lazy connection.

ThinkPHP's model layer supports multi-layer design. You can perform more detailed design and division of labor on the model layer, such as dividing the model layer into logical layer/service layer/ Event layer and so on.

View

The data returned after the controller calls the model class is assembled into different formats of output through the view. The view decides to call the template engine to parse the content and then output it or output it directly according to different needs.

Views usually have a series of template files corresponding to different controllers and operation methods, and support dynamically setting the template directory.

Driver

Many components of the system adopt driver design, which can be expanded more flexibly. The location of the driver class is placed under the core class library directory by default. You can also redefine the namespace of the driver class library and change the driver's file location.

Behavior

行为（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的自动加载规范。

相关推荐：

搭建自己的PHP MVC框架

thinkPHP交易详情查询功能

The above is the detailed content of Overview of the overall architecture of thinkPHP5.0 framework [application, module, MVC, driver, behavior, namespace, etc.]. For more information, please follow other related articles on the PHP Chinese website!