PHP实际项目开发中的增删查改业务逻辑经验(提高效率,规范,优化)

做增删查改业务逻辑也一年多了,做一下总结!!(函数=方法=接口)

1.设计数据库表时,相关的字段能放一个表里尽量放一个表中,比如分类,订单货品,这些没必要分开另起一个表。这样做的好处是后期不用太多的连表查询和方便做统计。相关示例

2.开发的接口应该具备解耦合(相关理解耦合度),集中性,拆分性

  • 解耦合:提高可用性,一个接口既能这样,又能那样,无懈可击那种。因为需求随时都会变,今天这样,明天那样,假如你做出的接口仅仅只适合用于今天的需求,比如需求是获取未配送的订单,那你写一个接口仅仅是获取未配送的订单,太单一了,明天产品经理来跟你说,这里不显示未配送的订单,显示已配送的订单,那你做好的接口就得改,是不是很烦。所以思路当然是做个万能的接口了。
    • 把订单状态参数作为方法的参数,不写死
    • 让前端根据页面需要什么订单状态的单传对应的参数值给你。
    • 这样我管产品经理需求的订单状态怎么变,数据错误也是前端传错参数值而已,直接甩锅给前端。
    • 相关示例
  • 集中性:功能类似的接口,尽量合并写在一个接口中。这样做的好处是假如需要改动接口,只需找到这个合并的接口就行了,不需找出许多个接口,避免万一漏了哪个接口没改。而且这也利于前端对接,只要前端操作对接成功一次,之后再对接就不会找你问这个接口怎么对接了。比如有多种订单,不同页面显示不同的订单和显示不同的相关数据,那这几个页面对应的接口功能就是显示对应订单的数据,可以合并成一个接口。
    • 和以上解耦合的方法一样
    • 让前端传你设置好的对应参数值过来
    • 用switch()根据不同值执行相关的操作
    • 然后把所有相关的数据都返回给前端
    • 前端挑选有用的信息输出就好了
    • 相关示例
  • 拆分性:一个接口里面实现的东西,我们可以把里面的东西拆分开来,用一个专一性的接口装着,需要的时候调用这个专一性接口就行了。这样做的好处是:使接口看起来简洁,分工明细,而且拆分出来做成的专一性接口也可以用于其他接口中,减少代码冗余,可重复性运用。

3.灵活运用switch(){case:break;default:},实现接口的多功能性

4.遵守MVC架构:也就是所谓的封装。(怎么优雅怎么来!!)

  • 所有的数据库操作和大部分的业务逻辑写在M
  • 网站页面写在V
  • 响应用户请求以及决定如何展示数据的逻辑写在C

建议尽量细分,这样做的好处是分工明细,改的时候专注一个地方改。以前我也觉得M好像多余的,但想了想,假如把对数据库的操作M都写在C中,有一天产品经理说把之前所有的统计总数换成计算最大或最小值,那是不是所有用过统计总数的地方都要改,如果项目又很大,你很多C里面用过,那找到什么时候,改到什么时候,所以把对数据库的操作和相关的业务逻辑抽取出来放在M中,需要改时,直接找到这个M中的这个方法,修改一下,所有在C中运用的就都改了。

没有更多推荐了,返回首页