本文介绍通过提取验证逻辑、使用函数式编程风格和统一异常处理，让服务层输入校验更清晰、可维护、可复用。
本文介绍通过提取验证逻辑、使用函数式编程风格和统一异常处理，让服务层输入校验更清晰、可维护、可复用。
在典型的 Spring 或 Java 服务层开发中，业务方法常需对入参（如 DTO）执行多重非空、格式、业务规则校验。若将所有校验逻辑直接内联在方法体中（如 if (user.getId() == null) 嵌套堆叠），不仅导致主流程被干扰，还严重损害可读性、可测试性与复用性——正如原始代码所示：校验分散、重复、缺乏语义表达，且关键业务路径（如创建/更新用户）被校验噪声掩盖。
一个更干净的实践是将校验职责单一化、模块化、声明化。推荐采用以下三层优化策略：
✅ 1. 提取专用验证方法，明确职责边界
将校验逻辑封装为私有工具方法（如 validateUser(UserDto)），使主方法聚焦于核心业务流。该方法应返回 void（校验失败即抛异常），而非布尔值，避免调用方误判或忽略返回值：
private void validateUser(UserDto user) {
if (user == null) {
throw new CustomHandledException("User must not be null");
}
if (user.getId() == null) {
throw new CustomHandledException("User ID is required");
}
if (user.getGivenName() == null || user.getGivenName().trim().isEmpty()) {
throw new CustomHandledException("Given name is required");
}
if (user.getEmail() == null || !RequestValidator.validateEmail(user.getEmail())) {
throw new CustomHandledException("Valid email is required");
}
if (user.getLocale() == null) {
throw new CustomHandledException("Locale is required");
}
if (!user.getGivenName().startsWith("text")) {
throw new CustomHandledException("Given name must start with 'text'");
}
}
? 提示：校验消息应具体（如
"User ID is required"），便于前端或日志快速定位问题；避免泛化"example"占位符。
✅ 2. 使用函数式组合提升可读性与复用性（进阶）
若项目已引入 Guava、Vavr 或自定义工具类，可进一步用 Predicate 组合校验规则，增强表达力与复用性：
private void validateUser(UserDto user) {
final Predicate<userdto> hasId = u -> u.getId() != null;
final Predicate<userdto> hasName = u -> u.getGivenName() != null && !u.getGivenName().trim().isEmpty();
final Predicate<userdto> hasValidEmail = u -> u.getEmail() != null && RequestValidator.validateEmail(u.getEmail());
final Predicate<userdto> hasLocale = u -> u.getLocale() != null;
final Predicate<userdto> nameStartsWithText = u -> u.getGivenName().startsWith("text");
if (!Stream.of(hasId, hasName, hasValidEmail, hasLocale, nameStartsWithText)
.allMatch(p -> p.test(user))) {
throw new CustomHandledException("User validation failed: missing or invalid fields");
}
}</userdto></userdto></userdto></userdto></userdto>
✅ 3. 避免常见陷阱
-
不要在验证方法中返回
boolean并由调用方决定是否抛异常 —— 这破坏契约一致性，易引发漏校验； -
避免在
getUserById()后对user.getGivenName()等字段做“补救式校验” —— 校验应前置，确保入参合法后才发起远程调用； -
勿将校验逻辑与业务逻辑耦合（如
updateUser()前临时加校验）—— 所有写操作前均应通过同一入口校验； -
考虑 AOP 方案（如
@Valid+@Validated+ 自定义 ConstraintValidator）用于通用场景，但复杂业务规则仍建议显式方法调用，保障可调试性与可读性。
最终重构后的主方法简洁有力，业务意图一目了然：
public void exampleMethod(final UserDto user, String sthElse) {
validateUser(user); // ✅ 清晰、前置、强契约
if (sthElse == null) {
throw new CustomHandledException("sthElse is required");
}
GetUserResponseDto response = client.getUserById(user.getId(), country);
if (response == null) {
client.createUser(UserMapper.toCreateBody(user));
return;
}
if (user.getLocale().equals(response.getUser().getProfile().getLocale())) {
return;
}
client.updateUser(user); // ✅ 此时 user 已全量验证通过
}
总结：清洁的输入校验 = 显式职责分离 + 语义化命名 + 前置执行 + 具体错误提示。它不是“少写几行 if”，而是构建可演进、易协作、抗变化的服务契约基石。
