Listening to the Words

thinkphp5 之 开发建议

好的代码的第一原则不是性能,而是代码的可读性,绝大多数的产品,对性能的要求远没有想象的高

变量篇

  • 避免直接获取系统变量,用Request对象的相关方法替代;(laravel无法直接获取变量,必须使用request类或者input辅助函数)

  • 不管是get还是post请求,统一使用param方法获取当前请求(任何类型请求)变量【统一方便】

  • 不要直接操作改变当前请求的系统变量

  • 使用操作方法的参数绑定功能,而不是自己手动获取请求参数

  • 使用依赖注入(tp5的依赖注入非常的简单)

  • 对于一些请求用到的公共属性可以使用request属性注入

  • 用request类的getinput方法替代file_get_contents(‘php://input’)

  • 模板中输出系统变量使用{$Request.param.name}的方式

  • 多使用Request类的only和except方法获取多个请求变量

  • 不要直接操作$_SESSION变量

路由篇

  • 用动态注册方法而不是路由配置(惯例大于配置)

  • 不要在路由配置文件外定义路由

  • 用get/post/delete/put等路由注册方法明确制定请求类型

  • 保证路由变量和操作方法的参数绑定命名一致

  • 路由地址保持和实际控制器名和方法名一致

  • 为每个路由变量明确变量规则

  • 用路由分组简化路由定义和公共参数

  • 尽可能使用强制路由并配合MIIS路由

  • 优先考虑资源路由,尤其是API开发的时候

  • 考虑在路由后置行为中进行用以权限检测

  • 部署后记得执行路由缓存指令

  • 了解下路由的请求缓存对你会有帮助

控制器

  • 建议开启controller_suffix配置参数,并采用indexController命名控制器类

  • 原则上控制器类不需要继承think\controller

  • 给你的控制器类继承一个公共的积累例如Base便于统一调整

  • 需要的haul在你的基础控制器类中引入 traits\controller\jump

  • api开发尽量使用资源控制器

  • 控制器类中避免写太多业务逻辑,交有模型类完成

  • 尽量避免直接操作数据库类,而是在模型类中做好封装

  • 可能的话尽量在控制器层完成数据验证

  • 不要试图在初始化方法中调用redirect助手函数,而用$this->redirect方法代替

  • 始终在控制器方法中return而不是echo以免影响请求缓存

  • 用json、view以及redirect助手函数进行相应输出

  • 用abort助手函数抛出HTTP异常

  • 遵循驼峰法命名你的控制器类和文件名

  • 永远不要在操作方法中使用exit

数据库篇

  • 千万不要使用驼峰法命名数据表和字段

  • 如非必要避免直接操作db类

  • 用db类的name方法而不是table方法

  • 用视图查询view方法代替join方法

  • 查询操作尽可能的使用field方法,哪怕是field(true)

  • 如果要批量执行sql语句使用batchQuery方法

  • 用value方法获取单个记录的某个字段值

  • 用column方法获得多条记录的某个字段值

  • 灵活的使用cache方法进行查询缓存处理和删除

  • 使用fetchSql方法直接返回sql语句而不实际执行CURD

  • 部署之后记得执行命令行的php think optimize:schme指令

  • strict方法可以避免多余的数据字段抛出异常

  • 关于日期和时间的查询不放试试whereTime方法

  • 数据库的大多数操作都是自动参数绑定的,一般情况下无需手动使用bind方法

  • insert方法返回的影响的记录数而不是主键

  • 使用后insertGetid方法插入数据并返回主键

  • delete可以无条件删除数据
  • selec和find方法支持闭包,但尽量不要和链式操作混用

  • 需要查询大量数据并且分批处理的话使用chunk方法

  • 对find方法使用主键查询并且cache的话缓存是自动更新的

模型篇(上)

  • 不要认为模型性能比Db差,这点差别还抵不过一条sql查询,而带来的便利是可观的

  • 模型的好处千言万语抵不过两个字,对象

  • 模型类一般直接继承think、Model,如有必要的话不需要继承一个公共的类库

  • 如果你的模型类没有任何的数据库操作的话不要要继承任何类库

  • 模型类不需要使用类后缀Model

  • 模型的save方法既可以新增也可以更新(而且是自动识别)

  • 模型没有链式操作,所有链式操作都是调用的数据库类db

  • 模型支持事件而数据库类的操作不支持事件

  • 统一在模型的init方法中注册模型事件

  • 模型没有数据表前缀的概念,只有对应数据表的概念

  • 每个模型对应一个数据库查询对象,彼此独立

  • 每个模型可以单独定义自己的数据库连接信息

  • 模型名不一定就是数据表名字,而且可以单独定义数据表名称

  • 模型查询的数据返回永远都是当前模型对象实例,而不是数组,db类查询才是数组

  • 模板对象可以直接操作数组操作而不需要使用toArray转换

模型篇(下)

  • 模型的查询操作建议使用get和all方法(静态方法)

  • 要在模型查询中使用链式查询可以定义查询范围或者使用闭包

  • 用save方法更新数据的返回值是影响的记录数而不是主键值,获取主键直接获取当前模型对象即可

  • 如果仅仅是需要主键之外的查询条件的话,可以get或者all方法的第一个参数使用数组;要模型查询后的原始数据可以使用getData方法

  • 模型的关联操作可以让你省去很多的关联查询

  • 鉴于性能考虑,关联预载入查询绝对是关联查询的首选

  • 一对一的关联关系,尤其是主表和附表的关系考虑使用聚合模型

  • 软删除必须使用模型的delet方法而不是数据库类的delete方法

  • 不要再修改器中修改多个属性

  • 修改器是模型才有的功能,调用数据库db类的写入操作方法是不会被触发的

  • 不要在同一个模型实例中多次调用save新增数据,一旦新增成功后,再次save就是更新数据了。

点赞