这半个月断断续续在学习用PHP的ThinkPHP框架开发后端API。现在总结记录一下开发一个接口需要做好哪些事,以此提高开发效率,并且也有不错的扩展性。
一、流程概要
基本是这么一个流程,略过环境搭建:
- 整理清楚有哪些接口
- 设计数据表
- 初步梳理是一对一,一对多,还是多对多
- 编写验证器
- 编写全局异常类(AOP思想)
- 定义路由路径
- 建立控制器类
- 建立模型类
- 用ORM,所以建立和数据表对应的模型类
- 控制器调用模型,模型调用数据库,完成接口编写
二、具体说明
梳理好有哪些接口后,就开始设计数据表:
数据表会随着代码的编写做些调整和改变。
值得注意的一点,当有两张表之间的关系是多对多时,记得设计一张中间表存放两张表各自的id。
设计好数据表后,开始编写一些工具类,有助于提高编写业务代码时的效率。
首先是验证器(validate)。
TP5框架自带验证器类,我们要做的则是继承这个验证器类,然后根据具体的接口做扩展即可。
创建一个验证器基类,把通用的方法放在里面:
goCheck()方法是所有具体验证器都会调用的方法,各个具体验证器只是会重写一些验证规则和验证返回信息而已。
在goCheck()方法里,实例化了Request类。这样做的目的是获取API被调用时,调用方传递的参数。获取到参数后,自然就是对这些参数进行验证了。check()方法会调用各个具体验证器里设置的验证规则函数进行检测。
然后是全局异常类(global exception)。
同样的,TP5框架自带了一个异常类,我们就创建一个异常基类继承它。
随后需要做的则是根据具体的接口重写HTTP状态码,错误消息和错误码即可。
至于错误码的定义,则是自己设计一套规范。
搭建好验证器和全局异常类后,我们只需要在每个接口的函数里面调用他们就行了:
好,至此一些基础的东西就搭建好了,下面开始编写接口代码。
首先定义路由路径:
在route.php里,引入Route类,定义路径即可。路径里的变量用:号+变量名表示,路径里的变量由路径末尾指定的函数接收,这个函数定义在控制器相对应的类里面。
比如id这个变量:
如上图,在控制器里,当拿到调用方通过路由路径传过来的参数后,我们就调用模型,把参数传过去,模型处理具体的数据库调用。
这里也是一个需要注意的点,控制器尽量只做连接的事情,不做具体的操作。
然后,在建立了控制器后,顺理成章,也需要建立对应的模型。
TP5同样自带了Model类,然后我们也定义自己的模型基类,当然也是继承TP5的模型类:
模型基类自然也是定义较为通用的方法。比如上图的例子里,定义了一个返回图片前缀链接的方法,不同的接口但又跟图片调用有关的话,就会用到这个方法来拼接图片URL。
这里也有个注意的点。当我们需要创建全局的变量时,可以在application目录下创建extra目录文件,然后创建setting.php文件,在里面返回一个关联数组即可:
随后的调用如上图模型基类里的prefixImgUrl方法里展示的一样,config函数,参数传入文件名加关联数组的key值,这样就可以获取到了:
回到模型上来,每个接口会有自己的模型类,这个模型类对应一张数据表,比如:
Banner模型类由于是通过模型基类继承了TP5的Model类,我们需要做的就是重写一些属性,来适应这个具体的接口,比如重写$hidden属性,定义这个接口返回的哪些字段我们是要隐藏的。
然后则是ORM的重点之一,调用数据表所对应的模型类。比如items方法里,通过hasMany()这个方法确定了Banner模型和BannerItem模型的关系。然后在getBannerById()方法里,调用了ORM用来操作数据的方法,这是对原生操作数据库语句的封装,然后ORM会返回模型对象,这个对象除了带有数据库数据外,还会带有一些属性和方法,用来操作数据。这是ORM对比原生SQL语句的一个优势。
最后,控制器调用模型的getBannerById()方法,获取到了数据,再作为接口的返回值传递给接口调用者。这样就完成了一次接口的编写。
三、总结
至此做了一个简要的后端API开发流程记录。其中还有很多细节没有提到,只是简略的描述了一个过程,不过这也不是这次记录的主要目的。这次的目的还是对这一周多学习的一个记录。
通过这次学习后端API开发,更加巩固了我对面向对象编程里思想的理解和运用。
通过继承和重写,可以把代码写得更干净简洁。
类,实例,属性,方法,怎么看待他们,然后操作他们,通过这次学习又加深了很多认识。
原创文章,作者:carmelaweatherly,如若转载,请注明出处:https://blog.ytso.com/272301.html