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

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

This article describes the overall architecture of thinkPHP5.0 framework. We will share this with you for your reference. The details are as follows:

ThinkPHP5.0 is organized based on MVC (Model-View-Controller.

MVC is a design pattern that forcibly separates the input, processing, and output of an application. MVC applications are divided into three core components: Model (M), view (V), and controller (C). They process their own tasks.

5.0 of URL access is determined by the route. If the route is disabled or no matching route exists, it is based on:

Http: // serverName/index. php (or other application entry file)/module/controller/Operation/parameter/value...

The following concepts need to be understood and may be mentioned later.

Portal File

The PHP file requested by the user is responsible for processing the lifecycle of a request (note, not necessarily a URL request). The most common entry file isindex.php, And sometimes add new entry files for some special needs, such as an entry file separately set for the background module.admin.phpOr a controller program entrythinkAll belong to the portal file.

Application

The application in ThinkPHP is a management system architecture and lifecycle object.\think\AppClass. Applications are usually called and executed in the entry file, with the same application directory (APP_PATH), But an application may have multiple entry files.

Applications have their own independent configuration files and public (function) files.

Module

A typical application consists of multiple modules. These modules are usually a sub-directory under the application directory. Each module has its own configuration file, public file, and class library file.

5.0 supports single module architecture design. If your application has only one module, the sub-directory 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. Multiple controllers under a module are responsible for responding to requests, and each controller is actually an independent controller class.

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

In fact, controllers in 5.0 can be skipped. Through routing, we can directly schedule requests to a model or other classes for processing.

5.0 of the controller classes are flexible, so you do not need to inherit any base class libraries.

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). The operation method is the smallest unit for accessing a URL.

The following is a typical definition of the operation method of the Index controller, which includes 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 use no parameters. If a non-optional parameter is defined, this parameter must be passed in through user requests. If it is a URL request, usually $ _ GET or $ _ POST is passed in.

Model

Model classes typically encapsulate actual business logic and data, and return data that is not related to the format.

The model class does not have to access the database. In the architecture design of 5.0, the database is connected only when the actual database query operation is performed, which is a real inert connection.

The model layer of ThinkPHP 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 the logic layer, service layer, and event layer.

View

The data returned after the Controller calls the model class is assembled into outputs of different formats through views. The view decides whether to call the template engine to parse the content and then output the content directly.

A view usually has a series of template files corresponding to different controllers and operation methods, and supports dynamic setting of template directories.

Driver

Many components of the system adopt the drive design, which can be expanded more flexibly. 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 File Location of the driver.

Action

Behavior is an action performed at a predefined application location. Similar to the "aspect" concept in AOP programming, binding related behaviors to a specific aspect becomes a kind of AOP programming idea. Therefore, the behavior is usually related to a specific location, and the execution time of the behavior depends on the location to which the behavior is bound.

To execute a behavior, you must first listen on the behavior in the application, for example:

// Listen for the action \ think \ Hook: listen ('app _ init ') at the app_init position ');

Then, bind the behavior to a location:

// The app_init position \ think \ Hook: add ('app _ init', '\ app \ index \ behavior \ test ');

If multiple behaviors are bound to a single location, they are executed in the order of binding, unless interrupted.

Namespace

ThinkPHP5 adopts the PHP namespace to design and plan class library files.PSR-4.