1. Modular Design
a complete thinkphp application is based on module/controller/Operation design, and, if necessary, can support multi-entry files and multi-level controllers.
A typical URL access rule is (we use the default pathinfo mode as an example, and of course we can support the normal URL pattern):
http://serverName/index.php (or other application entry file)/module/controller/operation/[parameter name/parameter value ...]
ThinkPHP3.2 applications can support switching to command-line access, if you switch to command-line mode, the following access rules are:
>php.exe index.php (or other application entry file) module/controller/operation/[parameter name/Parameters value ...]
Explain some of these concepts:
Name
|
Describe
|
Application
|
Projects that are accessed based on the same portal file we call an application. |
Module |
An application can contain multiple modules, each of which is a separate subdirectory under the application directory. |
Controller
|
Each module can contain multiple controllers, and a controller typically manifests itself as a controller class. |
Operation |
Each controller class can contain more than one action method, or it may be a binding action class, with each operation being the smallest unit of URL access |
The idea of modular design the following module is the most important part, and the module is actually a collection of configuration files, function files, and MVC files (directories).
The new version uses a modular design architecture, the following is an application directory under the module directory structure, each module can be easily uninstalled and deployed, and support the public module.
Application default app directory (can be set) ├─common public module (not directly accessible) ├─home foreground module ├─admin backend module ├─ ... Additional modules ├─runtime Default runtime directory (can be set)
Each module is relatively independent and its directory structure is as follows:
├─module Module Directory │├─conf configuration file directory │├─common common functions directory │├─controller Controller Directory │├─model Model catalog │├─logic logical directory (optional) │├─service Service directory (optional) │ ... More Hierarchical catalogs optional │└─view view catalog
Because of the multi-layered MVC mechanism, in addition to the Conf and common directories, the directory structure under each module can be flexibly set up and added as needed, so it is not rigidly tied to the directory shown above.
Public module
The Common module is a special module that is the public module of the application, and before all modules are accessed, the configuration files under the public module are loaded first ( Conf/config.php
) and Public function files ( Common/function.php
). However, the common module itself cannot be accessed directly via a URL, and other files of the public module can be inherited or invoked by other modules.
The location of the public module can be changed by Common_path constants, and we can redefine the Common_path in the portal file as follows:
Define (' Common_path ', './common/');
Define (' App_path ', './application/');
Require './thinkphp/thinkphp.php ';
Its application directory structure becomes:
www Web Deployment directory (or subdirectory)
├─index.php Portal File
├─readme.md README File
├─common Application Public Module Catalog
├─application Application Module Catalog
├─public Application Resource Files directory
└─thinkphp Framework Catalog
Once defined, the common directory is no longer required under the application directory.
Automatically generate module catalogs
from 3.2. Version 2 Initially, you can support automatic generation of module catalogs outside of the default modules, as well as batch build controllers and model classes.
For example, if we need to generate an admin module for a background app, define the following in the app portal file:
Binding the Admin module to the current portal file
Define (' Bind_module ', ' Admin ');
Define (' App_path ', './application/');
Require './thinkphp/thinkphp.php ';
Then access the URL address
http://serverName/index.php
admin\controller\ Indexcontroller
build_controller_list
Binding the Admin module to the current portal file
Define (' Bind_module ', ' Admin ');
Define (' Build_controller_list ', ' index,user,menu ');
Define (' App_path ', './application/');
Require './thinkphp/thinkphp.php ';
The three specified controller classes are automatically generated after access:
Admin\controller\indexcontroller
Admin\controller\usercontroller
Admin\controller\menucontroller
Note: The default generated controller classes are inherited Think\Controller
, if you need to inherit other public classes, you need to adjust further. If the settings are turned off in the public profile of the app APP_USE_NAMESPACE
, the generated controller class is not defined by the namespace.
You can also call Think\Build
it yourself manually class to generate the controller class, for example:
Generate the role controller class for the admin module
Default class library is Admin\controller\rolecontroller
Does not regenerate if it already exists
\think\build::buildcontroller (' Admin ', ' Role ');
Similarly, you can also define BUILD_MODEL_LIST
support for generating multiple model classes:
Binding the Admin module to the current portal file
Define (' Bind_module ', ' Admin ');
Define (' Build_controller_list ', ' index,user,menu ');
Define (' Build_model_list ', ' user,menu ');
Define (' App_path ', './application/');
Require './thinkphp/thinkphp.php ';
Access automatically generates model classes:
Admin\model\usermodeladmin\model\menumodel
Note: The default generated model classes are inherited Think\Model
, if you need to inherit the common model class, you need to adjust further. If the setting is closed in the public profile of the app APP_USE_NAMESPACE
, the resulting model class will not be defined with a namespace.
You can also manually invoke the method of the Think\build class to generate the model class, for example:
Generate the role model class for the admin module
Default class library is Admin\model\rolemodel
Does not regenerate if it already exists
\think\build::buildmodel (' Admin ', ' Role ');
Disable access to modules
3.2 Access to the module is automatically judged, so there is usually no need to configure a list of modules to access, but you can configure a list of blocked modules (for calls by other modules or not open access), which is forbidden Common
in the default configuration modules and Runtime
module (runtime directory is the default run-time directory), we can add additional block access to the list of modules:
Set list of blocked modules
' module_deny_list ' = = Array (' Common ', ' Runtime ', ' Api '),
Once set, the API module cannot be accessed directly through a URL, in fact, we may just place some common interface files under the module, so it is all internal calls.
Set up access lists
If your app has fewer modules below, you can also set the Allow access list and the default module, which simplifies URL access for the default module.
' module_allow_list ' = = Array (' Home ', ' Admin ', ' User '),
' Default_module ' = ' Home ',
After Setup, modules other than home, admin, and user modules cannot be accessed directly, and the home module is the default Access module (which may not appear at the URL address).
Single module design
If your application is simple enough, it may be done with just one module, so you can set it directly:
Turn off multi-module access
' Multi_module ' = False,
' Default_module ' = ' Home ',
Once you turn off multi-module access, you can only access the default module (home is set here).
The public module is still valid after the single module design.
Multi-entry Design
You can set up multiple portals for the same application and modules, and different entry files can be configured with different application modes or binding modules.
For example, we are index.php
the file's sibling directory adds a home.php
portal file, and bind the home module:
Bind home module to current portal file
Define (' Bind_module ', ' Home ');
Define (' App_path ', './application/');
Require './thinkphp/thinkphp.php ';
After binding the module, the original access address
Http://serverName/index.php/Home/Index/index
will become
Http://serverName/home.php/Index/index
This article is from the "Little Prince" blog, please be sure to keep this source http://littleprince.blog.51cto.com/1491292/1617964
thinkphp Study Notes (v) Modular design