tp框架使用心得

时间:2021-07-10 16:29:52

防止tp框架在update表时报错

我们知道在对数据库进行update操作时如果对表数据没有进行任何修改时是会报错的,而当我们将结果返回给用户时,用户肯定不知道是因为他没有进行任何操作导致的报错,他们最直观的反映就是系统出错了,接着就是一片惶恐。

所以为了防止上述情况的发生,可以试着在表结构中添加一个update_time字段,每次updtae时获取当前的timestamp,这样可以保证用户每次的编辑都成功。

modal的爱恨情仇

这个纯属于我个人的意见,那就是在modal中不要封装该modal 之外的表的数据处理,除非是与该modal一体的数据,即主外键关系,因为虽然你可以将所有的业务逻辑处理放在modal中去实现,但是导致的结果就是这个modal的利用率很低,面对越来越多的需求,导致代码越写越多,这个modal也越来越庞大,牵一发而动全身。

返回错误与前端容错

这个也是一个习惯类的东西,比如后端进行业务逻辑处理时确定对某个变量返回给前端的结果是false,那么前端如何来保证后端返回false后也能正常运行而不报错呢?

/**
* 假设后端返回结果是:
* 正确结果:
{
name:[1,2,3,4]
}
* 但是由于name为空,所以返回 false
{
name:false
}
**/

fetch("",{credentials: 'include'})
.then((response)=>{ return response.json(); })
.then((responseData)=>{
// 这里添加一个 || 的容错符,当前面的值是false时,程序也能正常运作
let name= responseData.name || [];
})

web端与移动端接口是否可以公用?

理论上来说不会有很大问题,但是至少以我个人的经验来说我不建议这么做,因为一个很现实的例子就是当后端返回300多条数据给web端的时候,web端没有任何问题,但是提交给移动端后,移动端直接炸了,当时写的是微信小程序,直接报渲染层出现错误,而为了防止这个问题并且不重新再写一个接口,所以就在原始接口中加入了分页的功能,并且需要保证对原始接口不会产生影响,所以针对web端接口与移动端接口是否可以公用这个问题,我个人意见是如果是小数据接口,那么没有多大问题,但是大数据,即使是为了以后web端优化而添加分页也好,建议是重新写,或者在写之初就加入分页的设置。

当然问题不止这些,还有很多,接下来会专门针对这个问题写一篇博客的吧,应该吧。。。。。。