前言

在平时的系统开发中经常会有一些简单的系统设置,表单提交等需求。这些需求虽然开发起来并没有什么难度,但是时间会经常花在定义接口,和前端的沟通上,有时候一个表单的研发需求会拉慢研发的速度。对于业务开发来说,在保证系统稳定的情况下,一定要快。在这两年的业务开发中,逐渐学习并开发了一些快速构建增删改查接口的接口。希望通过这篇文章记录一下。

基于SQL的规则配置

其实对于所有此类型的增删改查来说,几乎都是单表操作,如果抽象成SQL无非就是最简单的集中方式。

  • 增: INSERT INTO %(table)s(%(fields)s)VALUES(%(values)s),
  • 删:DELETE FROM %(table)s WHERE ID=%(id)s,
  • 查: SELECT %(fields)s FROM %(table)s
  • 改: UPDATE %(table)s SET %(set_condition)s

如果通过SQL来实现的话,我们完全可以通过对表和表的每一列进行一个配置(规则),通过代码的形式找到对应的配置,然后构建出SQL, 然后传输给数据库,让数据库去执行SQL, 返回对应的结果。那么,当我们有新需求的时候,我们则可以对表进行相应的配置。
 
简易的逻辑图如下:

除了以上简单的配置外,其实我们还可以做更多。之前的只是能让后端快速的构造出接口,但是在前后端分离的情况下,沟通成了开发中更大的成本。那么有没有一种方式,将我们后端配置的规则,传到前端去,转换成前端的语言,然后前端拿到后端的规则,通过代码自动实现构造页面,表单?其实是可行的。这样有什么好处呢?前后端通过规则这样的方式形成一种默契,省去了前后端的沟通,如果前端将样式和逻辑分离,那么,每次需求来了之后,只需要请求对应的配置表,逻辑层进行复用,然后对样式层进行特殊处理。这样的话,就达到了之前所说的效果。让需求能得到快速开发并且也保证了它的稳定性。

那么我们来总结一下,上面的思路,后端写好配置,然后前端通过接口获取配置的相关信息。当然,前端获取的信息一定会是通过后端解析过的,以便于前端方便理解。前端通过解析配置构造出对应的表单。用户通过表单提交,前端通过配置校验数据,然后提交数据,后端收到数据后构造出SQL。

逻辑图如下:

总结

有人总说写业务是最无聊,最没有技术含量的事,其实我不觉得这样。对于后端来说,虽然是简单的写接口,如果多一份心也能玩出一些小花样来。足够好的代码架构能帮我们快速出功能,让框架更加稳定。

发表评论

电子邮件地址不会被公开。 必填项已用*标注