还是熟悉的口号:PHP 是世界上最好的语言
为什么会接触PHP
接触PHP完全是因为 Web 开发。由 PHP 天然与 HTML、JavaScript 有亲近感,也就是原生味儿十足。即使是PHP与HTML代码混杂,从某种角度而言,也能帮助初学者直观地了解 Web 技术机理。
从单页 PHP 页面到 MVC ,再到 改造原有 MVC 架构 到服务于前端 React 的 API 设计。那段在学校养闲食堂三楼创业园区的时光中,我写过 PHP 代码甚至比前端代码还要多。。。
基于MVC框架的改造之路
获取接触过 PHP MVC 开发的同学都了解过 Codeignitor 。与大部分的 MVC 模式一样,model
负责获取数据库元数据,controller
负责业务逻辑处理,view
负责前端页面的渲染,具体流程如下:
但随着 AJAX 技术的流行,MVC 模式也进行了一丝丝改进:
但在实际项目中,由于我们前端使用了 React ,相比较于传统的前端,我们已经将原来 view
层所需要处理的逻辑/用户操作完全交给了前端:
这样一来 MVC 我们只用到了 M 和 C,所以随着项目的不断迭代,controller
会变得越来越不堪重负。
面向视图 => 面向API
基本开发流程为:
-
model
层与数据库交互,获取元数据。 -
controller
层接受前端传递的参数,进行业务处理,并返回前端想要的JSON
格式。
当业务逻辑变得复杂,需求频繁更改的时候容易出现以下弊端:
-
JSON
格式不规范。 -
model
层和controller
层的业务紊乱。 - 新API需求提出之后可能会影响老API的正常使用,主要原因有:1、
model
函数被更改;2、API名冲突;3、API 参数名更改等等。 - 前后端沟通成本太大。
- 代码复用性低。
修改CI的结构并制定开发规范
- 首先在
model
层之上添加了一层,这里我们称之为logic
层,由于之前业务逻辑游离在model
和controller
之间,没有明确的一个规范,随着需求的变更和开发的迭代,两层处理的结构已经不能满足开发的需求,我们需要一层专门处理逻辑,将业务从model
和controller
中剥离出来。 - 在开发过程中我们发现,
model
层对数据库的操作(这里说的操作是除去业务的),都有共性,即都是通用的增删查改。我们把这些数据操作称为:CRUD
,它包括:Creact 、Read 、Update 、Delete。 以 User_model 为例:
class User_model extends CI_Model {
private $table = 'user';
private function __construct() {
$this->load->database();
}
public function add_user($data = array()) {}
public function get_user($u_id, $column = '*') {}
public function get_user_page($where = array(), $column = '*', $offset = 0, $limit = 100) {}
public function update_user($u_id, $data = array()) {}
public function delete_user($u_id) {}
public function is_user($where = array()) {}
}
- 在
logic
层中我们编写业务代码,如:把从model
中获取来的元数据进行处理,组装成前端想要的数据格式。 - 在
controller
中我们首先对所有的请求进行日志记录,身份校验,参数校验之后直接把过滤后的数据丢给logic
。这样子一来controller
只是充当了 路由 + 过滤器 的作用,如果之后修改 API ,前端的请求地址不需要修改,只要在logic
中修改或者重新一个方法就行了。 - 为了减少前后端沟通的成本,我们可以在
controller
中再做点文章,比如说前端在测试 API 的时候传过来一个事先约定好的key
然后controller
直接return
一个构造好的数据格式,方便前端进行参数的构造。