“暂存”校验逻辑探讨

1、背景

在业务中可能会遇到这种场景,前端页面元素多且复杂,一次性填完提交耗时很长,中间中断面临着丢失数据的风险。针对这个问题,“暂存”应运而生。

那“暂存”的时候,是否需要对数据校验,如何进行校验,就是本文探讨的内容。

2、前后端职责简介

探讨之前,先简单聊聊前后端的职责。

2.1 前端

负责数据的输入,并对输入的内容进行校验,保证数据正确性、完整性。

常见的校验逻辑有以下几种:

  • 必填项校验
  • 数据类型校验:金额、数字、日期
  • 数据格式校验:金额格式、日期格式、邮件格式、身份证格式
  • 长度校验

2.2 后端

负责数据的保存,保证数据持久化。

数据库保存数据,存在的限制:

  • 数据类型:数字、日期、字符串
  • 数据长度

3、校验逻辑探讨

3.1 业务合理性

站在业务角度看,暂存是要把已填的数据先存起来,其实没有任何校验逻辑也没问题。

没有任何校验,就意味着数据可以随便输入,也就意味着会有错误数据保存:比如金额输入的是汉字等。

所以暂存是否允许输入错误数据呢?这是一个核心问题。

方案         优点 缺点
不做任何校验 随便存 有错误数据
不做必填项校验,其它校验需要做:填就填对

1、数据正确

2、填多少保存多少

要填就得填正确,略有限制

3.2 技术实现方案

技术方案         优点 缺点
不做任何校验 1、暂存时直接去掉校验逻辑,前端简答

1、后端数据库有类型限制,想达到这个效果有2种方式:

  • 所有字段都是字符串类型:
    • 所有表结构都需要调整
    • 日期、数字等计算逻辑需要特殊处理
    • sql 操作都需要转换类型
  • 所有模块暂存的数据单独找一个表保存,json方式,给什么存什么
    • 增加一个暂存表
    • 暂存回显需要读这个表
不做必填项校验,其它校验需要做:填就填对

1、后端数据可以正常保存在数据库

1、前端暂存时需要排除必填项校验

3.3 总结

系统的核心是流程及数据,站在这个角度看,数据是需要保证正确性的。

综合考虑业务需求、实现难度,我认为暂存应该只去掉必填校验,其它校验保留。

你可能感兴趣的:(工作总结,架构)