ThinkPHP Framework Design and extension

This article describes in detail the layer and url routing of the ThinkPHP framework, ThinkPHP extensions, database-driven extensions, Behavior extensions, and source code analysis and deficiencies. It provides a comprehensive and systematic explanation,

This article describes in detail the layer and url routing of the ThinkPHP framework, ThinkPHP extensions, database-driven extensions, Behavior extensions, and source code analysis and deficiencies. It provides a comprehensive and systematic explanation,

ThinkPHP framework is a widely used php framework in China. Let's take a look at some simple development examples to learn more about the ease of development and the scalable design that this framework brings to us. At the same time, we also look at some shortcomings of the framework from the perspective of source code analysis, and try to make a comprehensive and objective evaluation. Assume that you have used the ThinkPHP framework. for basic usage instructions, see the official documentation.

I. Framework hierarchy and url Routing

The installation of the framework is very simple. You can download the framework and put it in the web server directory. However, we recommend that you do not use the default entry file location, but put it in a separate directory to protect code and data. For example, the configuration directory of my portal file and web server is in the web directory (index. php In the outer framework is not deleted but not used ):

Like most MVC frameworks, we only need to expand our Controller and View according to the directory structure of the Framework, and some pages will be developed. ThinkPHP provides a Module, Controller, and Action layer-3 structure to organize its own URLs (Version 3.1 is called grouping, Action, and method, and version 3.2 is more international). The directory structure is as follows:

We strongly recommend that you:
1. Separate business layers without putting them in the Controller and Model. For example, I use the extended function library Application/Common/function. php to forcibly define the Service layer name as Service:

Function service ($ name)
{
Return D ($ name, 'service ');
}

The advantage is good reusability. If you want to develop wap pages and write different controllers in the future, you can reuse the service. If data storage changes in the future, for example, if you migrate a database from mysql to mongodb, you can modify the Model and the service still does not need to be modified.

2. The basic modules and business modules are separated and do not reference each other. Basic modules (such as basic user information) only provide data interfaces without Controller and View.
The layer-3 directory can be used for general web applications. For more complex web applications, we can define different entry files to load different applications. More complex applications? Portal and ultra-large-scale websites, it is not a php framework that can solve all the problems. You need your own middleware and custom framework.

ThinkPHP supports four url access modes:

1. Common Mode: Traditional url mode. All parameters are separated, for example
? M = Ucai & c = User & a = index detail = xxx
Route parameter: m parameter indicates the module, c indicates the controller, and a indicates the access method.
2. compatibility mode
? S =/Ucai/User/index/para/xxx
Route parameters are assembled by s parameters. Of course, data parameters do not need to be placed in s parameters.
3. pathinfo Mode

In this mode, the entry file and the real script are put together, with a clear meaning and convenient SEO
4. rewrite Mode

In this mode, you can use the rewrite configuration of the web server to hide the entry file, which is more friendly.
The pathinfo and rewrite modes must be supported by the web server. ThinkPHP has a configuration that needs to be set to which mode, which is actually used to generate url links in the U method. when accessing ThinkPHP, you only need to use which method the web server supports.
We also recommend that ThinkPHP do not need to be configured, but remember the user access mode. As long as the first access mode is used, the url generated in the future will be generated in this mode, because the user has already accessed it, there is no support issue.

If the normal url cannot meet our requirements, we can further optimize the url by configuring the route. For example, we want to make url configuration easier.

You only need to add the following routing configuration in the module configuration file. If you use a regular expression, it can be simpler.

'Url _ ROUTE_RULES '=> array (
'Login/: para' => 'ucai/User/Index ',
'Login' => 'ucai/User/Index ',
),

Here we can see that the ThinkPHP framework supports a wide range of layers and url configurations, meeting various requirements. Of course, we recommend that you do not misuse route configurations. A small number of configurations can bring better seo results, but a large number of configurations will make it difficult to maintain and modify the project.

Ii. ThinkPHP Extension

ThinkPHP is rich in components and drivers. Let's take database-driven extension and behavior extension as an example to learn about ThinkPHP's extension design.

Iii. database-driven Scaling

ThinkPHP provides many database drivers, but it cannot meet all requirements. For example, our data may not be implemented through direct access to the database, but through some middleware (such as C program) for forwarding to achieve better performance, in this case, you need to extend the database driver to support.
Expansion is very simple. you can create your own Driver in the DB/Driver directory, for example, Custom. php, and then implement the extension of the request and execute methods, and then configure DB_TYPE = 'custom' in the configuration file. Here, the request indicates a query, and the execute indicates changing the data. All other operations will be parsed in the Model and packaged into an SQL statement to call these two methods for execution.
For example, the simplest query method I implemented is to use shell commands to call sqlite to execute SQL statements:

Public function query ($ str ){
$ Cmd = sprintf ('sqlite3% s "% s" ', $ this-> config ['params'] ['dbfile'], $ str );
Exec ($ cmd, $ arr );
}

Of course, this is just an example. ThinkPHP itself supports sqlite3 and can be connected through pdo. The actual application environment may be to access the intermediate layer port through the layer-4 protocol to obtain data.

4. Behavior Scaling

Behavior design is the core of the ThinkPHP framework. Through Behavior configuration and expansion, it provides maximum support for system scalability and customization.
If we want to add the login verification function, we will design our own parent class Controller as usual, and then all other controllers will inherit from it. However, with Behavior, it becomes simpler and more flexible. We only need to add a Behavior in tags. php (if not, create a new one in the configuration directory:

Return array (
'Action _ begin' => array ('ucai \ Behavior \ AuthBehavior '),
'View _ begin' => array ('ucai \ Behavior \ OutputBehavior '),
);

This Behavior will be called when the program executes the action_begin process. We can jump to or terminate the execution according to the status.

Namespace Ucai \ Behavior;
Class AuthBehavior {
// The execution entry for behavior extension must be run.
Public function run (& $ return ){
// Set the action that does not need to be verified to true.
If (! $ Return ['auth _ public']) {
If (service ('user')-> checkLogin ())
{
$ Return = true;
}
Else
{
Header ('content-Type: text/html; charset = UTF-8 ');
Redirect (U ('user/Index', array ('url' = >$ _ SERVER ['HTTP _ referer']), 5, 'login required, jump in 5 seconds... ');
}
}
}
}

For pages that do not require logon, you can add configurations to the Controller. logon verification is required for all pages that do not require logon.

Public $ config = array ('auth _ public' => true );