如何检查DTO是否为空并优化isEmpty方法实现?
优化多属性DTO的空值校验方案
我最近碰到个场景:手里有个带9个String属性的DTO,需要校验它是否为空。参考相关内容后写了个isEmpty方法,但总觉得实现太糙,想找优化思路。先把我最开始的代码贴出来,再说说后来怎么优化的。
初始实现
原始isEmpty方法
public class BizDto { private String attr1; private String attr2; // 剩下7个属性就不一一罗列了 public boolean isEmpty() { return (attr1 == null || attr1.isEmpty()) && (attr2 == null || attr2.isEmpty()) && // 这里重复写剩下7个属性的判断,冗余感拉满 (attr9 == null || attr9.isEmpty()); } }
API里的调用逻辑
@PostMapping("/check") public ResponseEntity<String> checkDto(@RequestBody BizDto dto) { if (dto.isEmpty()) { return ResponseEntity.badRequest().body("DTO不能全为空"); } // 后续业务处理 return ResponseEntity.ok("校验通过"); }
初始代码的问题
一眼就能看出毛病:
- 代码冗余度极高,9个属性的判断逻辑重复书写,后续修改属性时很容易遗漏
- 灵活性太差,这个
isEmpty只能判断所有属性全空,但业务里经常需要校验部分属性组合的空值情况,完全满足不了多样化需求
优化后的最终实现
后来我调整了思路,把单一的isEmpty拆成多个对应不同业务场景的校验方法,同时抽了个通用工具方法减少重复代码:
优化后的DTO代码
public class BizDto { private String attr1; private String attr2; private String attr3; // ... 剩下6个属性 // 抽个通用方法,统一判断字符串是否为空(这里加了trim,可根据业务需求调整) private boolean isStrEmpty(String str) { return str == null || str.trim().isEmpty(); } // 原需求:判断所有属性全为空 public boolean isAllAttrsEmpty() { return isStrEmpty(attr1) && isStrEmpty(attr2) && isStrEmpty(attr3) && // ... 剩下6个属性的判断 isStrEmpty(attr9); } // 业务场景1:校验核心属性(比如attr1、attr2、attr3)是否为空 public boolean isCoreAttrsEmpty() { return isStrEmpty(attr1) && isStrEmpty(attr2) && isStrEmpty(attr3); } // 业务场景2:校验可选属性组(比如attr4、attr5)是否为空 public boolean isOptionalGroupEmpty() { return isStrEmpty(attr4) && isStrEmpty(attr5); } // 可根据业务需求新增更多针对性的校验方法 }
优化后的API调用
现在能根据不同业务场景调用对应的校验方法,逻辑更清晰:
@PostMapping("/submit") public ResponseEntity<String> submitDto(@RequestBody BizDto dto) { if (dto.isCoreAttrsEmpty()) { return ResponseEntity.badRequest().body("核心属性不能为空"); } // 可选属性组非空时做额外处理 if (!dto.isOptionalGroupEmpty()) { // 处理可选属性的业务逻辑 } return ResponseEntity.ok("提交成功"); }
额外的优化小建议
- 要是项目里引入了Apache Commons Lang或者Guava,直接用
StringUtils.isBlank(str)或者Strings.isNullOrEmpty(str)代替自定义的isStrEmpty,省得重复造轮子 - Spring项目的话,还可以用JSR-380的注解(比如
@NotBlank、@NotNull)配合@Valid做声明式校验,代码会更简洁 - 如果DTO的属性组合特别复杂,试试建造者模式,从构建阶段就保证DTO符合业务规则,减少后续校验的麻烦
内容的提问来源于stack exchange,提问作者Grismak
相关产品推荐
相关产品推荐

