本文共 1271 字,大约阅读时间需要 4 分钟。
数据库表设计与前端联调的难关
在业务新增功能开发过程中,我负责处理前端传递的数据结构问题。系统的核心需求是对多的关系设计,基础信息存储在基础表中,详细信息存储在明细表中。根据业务逻辑,明细信息分为甲方来源、乙方来源和丙方来源三大类。
最初的数据结构设计如下:
public class RequestAddDto { // 基础信息 ... // 明细信息 - 甲方来源 @ApiModelProperty("明细信息 - 甲方来源") private List requestFirstAddDtos; // 明细信息 - 乙方来源 @ApiModelProperty("明细信息 - 乙方来源") private List requestSecondAddDtos; // 明细信息 - 丙方来源 @ApiModelProperty("明细信息 - 丙方来源") private List requestThirdAddDtos;} 在与前端进行联调时,发现Swagger文档中入参示例显示为null,直接将结构化文档传给前端进行测试。我准备了以下JSON格式:
{ "xx": "xx", "xx": "xx", "aAddDtos": [ {}, {} ], "bAddDtos": [ {}, {} ], "cAddDtos": [ {}, {} ]} 发现明细信息未能正确传输。经过断点调试,确认三个来源的数据都未传入。经过反复测试,终于发现问题出在变量名的命名上。将requestFirstAddDtos改为requestFirstAddDtos后,前端数据终于正确传送。
最终确定的 DTO 结构如下:
public class RequestAddDto { // 基础信息 ... // 明细信息 - 甲方来源 @ApiModelProperty("明细信息 - 甲方来源") private List requestFirstAddDtos; // 明细信息 - 乙方来源 @ApiModelProperty("明细信息 - 乙方来源") private List requestSecondAddDtos; // 明细信息 - 丙方来源 @ApiModelProperty("明细信息 - 丙方来源") private List requestThirdAddDtos;} 通过这次经历,我学会了在变量命名上更加谨慎,必要时可以通过调试工具快速定位问题。同时,建议在前端联调阶段多进行数据格式的验证,避免因细节问题浪费开发时间。
转载地址:http://uqii.baihongyu.com/