thinkPHP5.0 Framework Overall Architecture Overview "applications, modules, MVC, drivers, behaviors, namespaces, etc."

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

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

ThinkPHP5.0 applications are organized based on the MVC (model-View-Controller) approach.

MVC is a design pattern that makes it mandatory to separate the input, processing, and output of an application. Using an MVC application is divided into three core parts: Model (M), view (V), Controller (C), each of which handles its own tasks.

5.0 of the URL access is determined by the route, if the route is closed or if there is no matching route, it is based on:

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

Some of the concepts below need to be understood and may often be mentioned in the following sections.

Entry file

The PHP file requested by the user is responsible for the life cycle of a request (note, not necessarily a URL request), and the most common entry file is the index.php addition of a new entry file for some special needs, such as a separate entry file admin.php for the backend module or a controller program entry think belongs to the portal file.

Application

Application in thinkphp is a management system architecture and life cycle of the object, by the system's \think\App class, the application is usually called and executed in the portal file, with the same application directory ( APP_PATH ) application We think it is the same application, but an application may have multiple entry files.

The app has its own separate configuration file, public (function) file.

Module

A typical application is made up of multiple modules, usually a subdirectory under the application directory, each of which has its own separate configuration files, public files, and class library files.

5.0 support a single module architecture design, if your application has only one module below, then the subdirectory of this module can be omitted and modified in the application configuration file :

' App_multi_module ' =  false,

Controller

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

The controller is primarily responsible for receiving requests, and invoking the relevant model processing, and ultimately through the view output. Strictly speaking, the controller should not be too involved in the business logic processing.

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

The 5.0 controller class is flexible and can be used without inheriting 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), which are the smallest units accessed by a URL.

Here is a typical operation method definition for the index controller, which contains two action methods:

Namespace App\index\controller;class Index {public  function index ()  {    return ' index ';  }  Public Function Hello ($name)  {    return ' Hello, '. $name;  }}

The action method can use no parameters, and if a non-optional parameter is defined, the parameter must be passed in by a user request, or in the case of a URL request, usually $_get or $_post.

Model

Model classes typically complete the actual business logic and data encapsulation, and return data that is not format-independent.

Model classes do not necessarily have access to the database, and in 5.0 of the architecture design, only the actual database query operations, the database will be connected to the real lazy connection.

Thinkphp's model layer supports multiple layers of design, and you can design and work with a more granular model layer, such as dividing the model layer into a logical layer/service Layer/event layer, and so on.

View

The data returned by the controller after invoking the model class is assembled into different formats of output through the view. Depending on the requirements, the view decides whether to invoke the template engine for content resolution output or direct output.

Views typically have a series of template files that correspond to different controllers and action methods, and support the dynamic provisioning of template catalogs.

Driven

Many of the components of the system are driven and can be extended flexibly, where the location of the drive class is placed by default in the core class library directory, or the drive-class library's namespace can be redefined to change the drive's file location.

Behavior

Behavior (Behavior) is something that is performed in a pre-defined application location. Similar to the concept of "tangent" in AOP programming, binding related behavior to a certain facet is a kind of idea of AOP programming. Therefore, the behavior is usually related to a location, and the execution time of the behavior depends on where it is bound.

To perform the behavior, you first want to listen for behavior in the application, for example:

Listen for Behavior \think\hook::listen (' App_init ') in app_init position;

Then bind the behavior to a location:

Binding behavior to App_init position \think\hook::add (' app_init ', ' \app\index\behavior\test ');

If multiple behaviors are bound in one location, they are executed in the order in which they are bound, unless an interrupt is encountered.

Name space

ThinkPHP5 uses PHP's namespace for class library file design and planning, and conforms PSR-4 to the automatic loading specification.