模块化设计
一个完整的ThinkPHP应用基于模块/控制器/操作设计,并且,如果有需要的话,可以支持多入口文件和多级控制器。
ThinkPHP新版采用模块化的架构设计思想,对目录结构规范做了调整,可以支持多模块应用的创建,让应用的扩展更加方便。
一个典型的URL访问规则是(我们以默认的PATHINFO模式为例说明,当然也可以支持普通的URL模式):
http://serverName/index.php(或者其他应用入口文件)/模块/控制器/操作/[参数名/参数值…]
ThinkPHP的应用可以支持切换到命令行访问,如果切换到命令行模式下面的访问规则是:
php.exe index.php(或其它应用入口文件) 模块/控制器/操作/[参数名/参数值…]
解释下其中的几个概念:
名称 | 描述 |
---|---|
应用 | 基于同一个入口文件访问的项目我们称之为一个用。 |
模块 | 一个应用下面可以包含多个模块,每个模块在应用目录下面都是一个独立的子目录。 |
控制器 | 每个模块可以包含多个控制器,一个控制器通常体现为一个控制器类。 |
操作 | 每个控制器类可以包含多个操作方法,也可能是绑定的某个操作类,每个操作是URL访问的最小单元。 |
模块化设计的思想下面模块是最重要的部分,模块其实是一个包含配置文件、函数文件和MVC文件(目录)的集合。
模块设计
新版采用模块化的设计架构,下面是一个应用目录下面的模块目录结构,每个模块可以方便的卸载和部署,并且支持公共模块。
Application 默认应用目录(可以设置)
├─Common 公共模块(不能直接访问)
├─Home 前台模块
├─Admin 后台模块
├─... 其他更多模块
├─Runtime 默认运行时目录(可以设置)
默认情况下,只要应用目录下面存在模块目录,该模块就可以访问,只有当你希望禁止某些模块或者仅允许模块访问的时候才需要进行模块列表的相关设置。
每个模块是相对独立的,其目录结构如下:
├─Module 模块目录
│ ├─Conf 配置文件目录
│ ├─Common 公共函数目录
│ ├─Controller 控制器目录
│ ├─Model 模型目录
│ ├─Logic 逻辑目录(可选)
│ ├─Service Service目录(可选)
│ ... 更多分层目录可选
│ └─View 视图目录
公共模块
Common模块是一个特殊的模块,是应用的公共模块,访问所有的模块之前都会首先加载公共模块下面的配置文件(Conf/config.php)和公共函数文件(Common/function.php)。但Common模块本身不能通过URL直接访问,公共模块的其他文件则可以被其他模块继承或者调用。
公共模块的位置可以通过COMMON_PATH常量改变,我们可以在入口文件中重新定义COMMON_PATH如下:
define('COMMON_PATH','./Common/');
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
其应用目录结构变成:
www WEB部署目录(或者子目录)
├─index.php 入口文件
├─README.md README文件
├─Common 应用公共模块目录
├─Application 应用模块目录
├─Public 应用资源文件目录
└─ThinkPHP 框架目录
定义之后,Application目录下面就不再需要Common目录了。
自动生成模块目录
可以支持自动生成默认模块之外的模块目录以及批量生成控制器和模型类。
例如,如果我们需要生成一个Admin模块用于后台应用,在应用入口文件中定义如下:
// 绑定Admin模块到当前入口文件
define('BIND_MODULE','Admin');
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
然后访问URL地址
http://serverName/index.php
就会生成Admin模块的目录,并生成一个默认的控制器类Admin\Controller\IndexController。 如果需要生成更多的控制器类,可以定义BUILD_CONTROLLER_LIST常量,例如:
// 绑定Admin模块到当前入口文件
define('BIND_MODULE','Admin');
define('BUILD_CONTROLLER_LIST','Index,User,Menu');
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
访问后会自动生成三个指定的控制器类:
Admin\Controller\IndexController
Admin\Controller\UserController
Admin\Controller\MenuController
注意:默认生成的控制器类都是继承Think\Controller,如果需要继承其他的公共类需要另外调整。 如果在应用的公共配置文件中设置关闭了 APP_USE_NAMESPACE的话,生成的控制器类则不会采用命名空间定义。
同样,也可以定义BUILD_MODEL_LIST支持生成多个模型类:
// 绑定Admin模块到当前入口文件
define('BIND_MODULE','Admin');
define('BUILD_MODEL_LIST','User,Menu');
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
访问会自动生成模型类:
Admin\Model\UserModel
Admin\Model\MenuModel
注意:默认生成的模型类都是继承Think\Model,如果需要继承公共的模型类需要另外调整。 如果在应用的公共配置文件中设置关闭了 APP_USE_NAMESPACE的话,生成的模型类则不会采用命名空间定义。
还可以自己手动调用Think\Build类的方法来生成控制器类和模型类,例如:
// 生成Admin模块的Role控制器类
// 默认类库为Admin\Controller\RoleController
// 如果已经存在则不会重新生成
\Think\Build::buildController('Admin','Role');
// 生成Admin模块的Role模型类
// 默认类库为Admin\Model\RoleModel
// 如果已经存在则不会重新生成
\Think\Build::buildModel('Admin','Role');
禁止访问模块
hinkPHP对模块的访问是自动判断的,所以通常情况下无需配置模块列表即可访问,但可以配置禁止访问的模块列表(用于被其他模块调用或者不开放访问),默认配置中是禁止访问Common模块和Runtime模块(Runtime目录是默认的运行时目录),我们可以增加其他的禁止访问模块列表:
// 设置禁止访问的模块列表
'MODULE_DENY_LIST' => array('Common','Runtime','Api'),
设置后,Api模块不能通过URL直接访问,事实上,可能我们只是在该模块下面放置一些公共的接口文件,因此都是内部调用即可。
设置访问列表
如果你的应用下面模块比较少,还可以设置允许访问列表和默认模块,这样可以简化默认模块的URL访问。
'MODULE_ALLOW_LIST' => array('Home','Admin','User'),
'DEFAULT_MODULE' => 'Home',
设置之后,除了Home、Admin和User模块之外的模块都不能被直接访问,并且Home模块是默认访问模块(可以不出现在URL地址)。
单模块设计
如果你的应用够简单,那么也许仅仅用一个模块就可以完成,那么可以直接设置:
// 关闭多模块访问
'MULTI_MODULE' => false,
'DEFAULT_MODULE' => 'Home',
一旦关闭多模块访问后,就只能访问默认模块(这里设置的是Home)。
单模块设计后公共模块依然有效
多入口设计
可以给相同的应用及模块设置多个入口,不同的入口文件可以设置不同的应用模式或者绑定模块。
例如,我们在index.php文件的同级目录新增一个admin.php入口文件,并绑定Admin模块:
// 绑定Home模块到当前入口文件
define('BIND_MODULE','Admin');
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
如果你更改了系统默认的变量设置,则需要做对应的模块绑定的变量调整。
绑定模块后,原来的访问地址
http://serverName/index.php/Admin/Index/index
就变成
http://serverName/admin.php/Index/index
同样的方式,我们也可以在入口文件中绑定控制器,例如:
define('BIND_MODULE', 'Home'); // 绑定Home模块到当前入口文件
define('BIND_CONTROLLER','Index'); // 绑定Index控制器到当前入口文件
define('APP_PATH','./Application/');
require './ThinkPHP/ThinkPHP.php';
绑定模块和控制器后,原来的访问地址:
http://serverName/index.php/Home/Index/index
就变成:
http://serverName/home.php/index
不同的入口文件还可以用于绑定不同的应用模式,参考应用模式部分。
URL模式
入口文件是应用的单一入口,对应用的所有请求都定向到应用入口文件,系统会从URL参数中解析当前请求的模块、控制器和操作:
http://serverName/index.php/模块/控制器/操作
这是3.2版本的标准URL格式。
可以通过设置模块绑定或者域名部署等方式简化URL地址中的模块及控制器名称。
URL大小写
ThinkPHP框架的URL是区分大小写(主要是针对模块、控制器和操作名,不包括应用参数)的,这一点非常关键,因为ThinkPHP的命名规范是采用驼峰法(首字母大写)的规则,而URL中的模块和控制器都是对应的文件,因此在Linux环境下面必然存在区分大小写的问题。
框架内置了一个配置参数用于解决URL大小写的问题,如下:
'URL_CASE_INSENSITIVE' => true,
当URL_CASE_INSENSITIVE设置为true的时候表示URL地址不区分大小写,这个也是框架在部署模式下面的默认设置。
当开启调试模式的情况下,这个参数是false,因此你会发现在调试模式下面URL区分大小写的情况。
URL模式
如果我们直接访问入口文件的话,由于URL中没有模块、控制器和操作,因此系统会访问默认模块(Home)下面的默认控制器(Index)的默认操作(index),因此下面的访问是等效的:
http://serverName/index.php
http://serverName/index.php/Home/Index/index
这种URL模式就是系统默认的PATHINFO模式,不同的URL模式获取模块和操作的方法不同,ThinkPHP支持的URL模式有四种:普通模式、PATHINFO、REWRITE和兼容模式,可以设置URL_MODEL参数改变URL模式。
URL模式 | URL_MODEL设置 |
---|---|
普通模式 | 0 |
PATHINFO模式 | 1 |
REWRITE模式 | 2 |
兼容模式 | 3 |
如果你整个应用下面的模块都是采用统一的URL模式,就可以在应用配置文件中设置URL模式,如果不同的模块需要设置不同的URL模式,则可以在模块配置文件中设置。
普通模式
普通模式也就是传统的GET传参方式来指定当前访问的模块和操作,例如: http://localhost/?m=home&c=user&a=login&var=value
m参数表示模块,c参数表示控制器,a参数表示操作(当然这些参数都是可以配置的),后面的表示其他GET参数。
如果默认的变量设置和你的应用变量有冲突的话,你需要重新设置系统配置,例如改成下面的:
'VAR_MODULE' => 'module', // 默认模块获取变量
'VAR_CONTROLLER' => 'controller', // 默认控制器获取变量
'VAR_ACTION' => 'action', // 默认操作获取变量
上面的访问地址则变成: http://localhost/?module=home&controller=user&action=login&var=value
注意,VAR_MODULE只能在应用配置文件中设置,其他参数可以则也可以在模块配置中设置
PATHINFO模式
PATHINFO模式是系统的默认URL模式,提供了最好的SEO支持,系统内部已经做了环境的兼容处理,所以能够支持大多数的主机环境。对应上面的URL模式,PATHINFO模式下面的URL访问地址是: http://localhost/index.php/home/user/login/var/value/
PATHINFO地址的前三个参数分别表示模块/控制器/操作。
不过,PATHINFO模式下面,依然可以采用普通URL模式的参数方式,例如: http://localhost/index.php/home/user/login?var=value 依然是有效的
PATHINFO模式下面,URL是可定制的,例如,通过下面的配置:
// 更改PATHINFO参数分隔符
'URL_PATHINFO_DEPR'=>'-',
我们还可以支持下面的URL访问: http://localhost/index.php/home-user-login-var-value
REWRITE模式
REWRITE模式是在PATHINFO模式的基础上添加了重写规则的支持,可以去掉URL地址里面的入口文件index.php,但是需要额外配置WEB服务器的重写规则。
如果是Apache则需要在入口文件的同级添加.htaccess文件,内容如下:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L]
</IfModule>
接下来,就可以用下面的URL地址访问了: http://localhost/home/user/login/var/value
更多环境的URL重写支持参考部署部分的URL重写。
兼容模式
兼容模式是用于不支持PATHINFO的特殊环境,URL地址是: http://localhost/?s=/home/user/login/var/value
可以更改兼容模式变量的名称定义,例如:
'VAR_PATHINFO' => 'path'
PATHINFO参数分隔符对兼容模式依然有效,例如:
// 更改PATHINFO参数分隔符
'URL_PATHINFO_DEPR'=>'-',
使用以上配置的话,URL访问地址可以变成: http://localhost/?path=/home-user-login-var-value
兼容模式配合Web服务器重写规则的定义,可以达到和REWRITE模式一样的URL效果。
例如,我们在Apache下面的话,.htaccess文件改成如下内容:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?s=/$1 [QSA,PT,L]
</IfModule>
就可以和REWRITE模式一样访问下面的URL地址访问了: http://localhost/home/user/login/var/value
多层MVC
ThinkPHP基于MVC(Model-View-Controller,模型-视图-控制器)模式,并且均支持多层(multi-Layer)设计。
模型(Model)层
默认的模型层由Model类构成,但是随着项目的增大和业务体系的复杂化,单一的模型层很难解决要求,ThinkPHP支持多层Model,设计思路很简单,不同的模型层仍然都继承自系统的Model类,但是在目录结构和命名规范上做了区分。
例如在某个项目设计中需要区分数据层、逻辑层、服务层等不同的模型层,我们可以在模块目录下面创建Model、Logic和Service目录,把对用户表的所有模型操作分成三层:
- 数据层:Model/UserModel 用于定义数据相关的自动验证和自动完成和数据存取接口
- 逻辑层:Logic/UserLogic 用于定义用户相关的业务逻辑
- 服务层:Service/UserService 用于定义用户相关的服务接口等
而这三个模型操作类统一都继承Model类即可,例如:
数据层:Home/Model/UserModel.class.php
namespace Home\Model;
use Think\Model;
class UserModel extends Model{
}
逻辑层:Home/Logic/UserLogic.class.php
namespace Home\Logic;
use Think\Model;
class UserLogic extends Model{
}
服务层:Home/Service/UserService.class.php
namespace Home\Service;
use Think\Model;
class UserService extends Model{
}
这样区分不同的模型层之后对用户数据的操作就非常清晰,在调用的时候,我们也可以用内置的D方法很方便的调用:
D('User') //实例化UserModel
D('User','Logic') //实例化UserLogic
D('User','Service') //实例化UserService
默认的模型层是Model,我们也可以更改设置,例如:
'DEFAULT_M_LAYER' => 'Logic', // 更改默认的模型层名称为Logic
更改之后,实例化的时候需要改成:
D('User') //实例化UserLogic
D('User','Model') //实例化UserModel
D('User','Service') //实例化UserService
对模型层的分层划分是很灵活的,开发人员可以根据项目的需要自由定义和增加模型分层,你也完全可以只使用Model层。
视图(View)层
视图层由模板和模板引擎组成,在模板中可以直接使用PHP代码,模板引擎的设计会在后面讲述,通过驱动也可以支持其他第三方的模板引擎。视图的多层可以简单的通过目录(也就是模板主题)区分,例如:
View/default/User/add.html
View/blue/User/add.html
复杂一点的多层视图还可以更进一步,采用不同的视图目录来完成,例如:
view 普通视图层目录 mobile 手机端访问视图层目录
这样做的好处是每个不同的视图层都可以支持不同的模板主题功能。
默认的视图层是View目录,我们可以调整设置如下:
'DEFAULT_V_LAYER' => 'Mobile', // 默认的视图层名称更改为Mobile
控制器(Controller)层
ThinkPHP的控制器层由核心控制器和业务控制器组成,核心控制器由系统内部的App类完成,负责应用(包括模块、控制器和操作)的调度控制,包括HTTP请求拦截和转发、加载配置等。业务控制器则由用户定义的控制器类完成。多层业务控制器的实现原理和模型的分层类似,例如业务控制器和事件控制器:
Controller/UserController //用于用户的业务逻辑控制和调度
Event/UserEvent //用于用户的事件响应操作
访问控制器 Home/Controller/UserController.class.php 定义如下:
namespace Home\Controller;
use Think\Controller;
class UserController extends Controller{
}
事件控制器 Home/Event/UserEvent.class.php 定义如下:
namespace Home\Event;
use Think\Controller;
class UserEvent extends Controller{
}
UserController负责外部交互响应,通过URL请求响应,例如 http://serverName/User/index,而 UserEvent负责内部的事件响应,并且只能在内部调用:
A('User','Event');
默认的访问控制器层是Controller,我们可以调整设置如下:
'DEFAULT_C_LAYER' => 'Event', // 默认的控制器层名称改为Event
所以是和外部隔离的。
多层控制器的划分也不是强制的,可以根据应用的需要自由分层。控制器分层里面可以根据需要调用分层模型,也可以调用不同的分层视图(主题)。
在MVC三层中,ThinkPHP并不依赖M或者V,甚至可以只有C或者只有V,这个在ThinkPHP的设计里面是一个很重要的用户体验设计,用户只需要定义视图,在没有C的情况下也能自动识别。