本文共 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/