本文旨在解决Spring应用中，如何针对不同类型的报告生成需求，设计可扩展且易于维护的请求参数验证方案。核心思路是利用继承和组合，结合Spring Validation框架，实现对抽象请求参数类的灵活验证，从而避免修改核心接口，提升代码的健壮性和可扩展性。
在Spring Boot应用中，处理不同类型的报告生成需求时，经常会遇到需要根据不同的报告类型，验证不同的请求参数。如果将所有可能的参数都放在一个DTO中，会导致DTO过于臃肿，且验证逻辑复杂。本文将介绍一种基于抽象类和继承的解决方案，结合Spring Validation框架，实现可扩展且易于维护的请求参数验证。
方案概述
核心思想是定义一个抽象的请求参数类ReportRequestDTO，其中包含所有报告类型通用的参数。然后，针对每种报告类型，创建具体的DTO类，继承自ReportRequestDTO，并添加该报告类型特有的参数。
在Controller层，接收ReportRequestDTO类型的参数，然后根据报告类型，将其转换为对应的具体DTO类型，并进行验证。
具体实现
1. 定义抽象请求参数类
import lombok.Data;
import javax.validation.constraints.NotEmpty;
@Data
public abstract class ReportRequestDTO {
@NotEmpty(message = "Foo不能为空")
private String foo;
@NotEmpty(message = "Bar不能为空")
private String bar;
}ReportRequestDTO定义了所有报告类型通用的参数foo和bar，并使用@NotEmpty注解进行非空验证。
2. 定义具体请求参数类
import lombok.Data;
import javax.validation.constraints.NotEmpty;
@Data
public class ReportADTO extends ReportRequestDTO {
@NotEmpty(message = "Foobar不能为空")
private String foobar;
}ReportADTO继承自ReportRequestDTO，并添加了ReportA类型报告特有的参数foobar，同样使用@NotEmpty注解进行非空验证。
3. Controller层实现
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;
import javax.validation.Valid;
import org.springframework.beans.factory.annotation.Autowired;
import javax.validation.Validator;
import java.util.Set;
import javax.validation.ConstraintViolation;
import org.springframework.http.HttpStatus;
import org.springframework.web.server.ResponseStatusException;
@RestController
public class ReportController {
@Autowired
private Validator validator;
@GetMapping("/report")
@ResponseBody
public ResponseEntity getReport(
@RequestParam(value = "category") String category,
@Valid ReportRequestDTO reportRequestDTO) {
// 根据category选择不同的DTO进行验证
if ("A".equals(category)) {
ReportADTO reportADTO = convertToReportADTO(reportRequestDTO);
validate(reportADTO);
// 调用生成ReportA的方法
return ResponseEntity.ok("ReportA generated with foobar: " + reportADTO.getFoobar());
} else {
validate(reportRequestDTO);
// 调用生成通用Report的方法
return ResponseEntity.ok("Generic Report generated");
}
}
private ReportADTO convertToReportADTO(ReportRequestDTO reportRequestDTO) {
ReportADTO reportADTO = new ReportADTO();
reportADTO.setFoo(reportRequestDTO.getFoo());
reportADTO.setBar(reportRequestDTO.getBar());
// 这里可以根据实际情况进行更复杂的转换
return reportADTO;
}
private void validate(T obj) {
Set> violations = validator.validate(obj);
if (!violations.isEmpty()) {
StringBuilder sb = new StringBuilder();
for (ConstraintViolation violation : violations) {
sb.append(violation.getMessage()).append("; ");
}
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, sb.toString());
}
}
} 在getReport方法中，首先根据category参数判断报告类型。然后，如果报告类型为A，则将ReportRequestDTO转换为ReportADTO，并使用validator.validate()方法进行验证。如果验证失败，则抛出异常。
注意:
- @Valid ReportRequestDTO reportRequestDTO 只是验证了ReportRequestDTO本身的约束，并不会验证子类的约束。
- 需要手动将ReportRequestDTO转换为对应的子类DTO，并进行验证。
- 可以使用javax.validation.Validator接口进行手动验证。
4. 全局异常处理 (可选)
为了更好地处理验证失败的情况，可以定义一个全局异常处理器，将ConstraintViolationException转换为友好的错误信息。
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import javax.validation.ConstraintViolationException;
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(ConstraintViolationException.class)
public ResponseEntity handleValidationException(ConstraintViolationException ex) {
return new ResponseEntity<>(ex.getMessage(), HttpStatus.BAD_REQUEST);
}
} 总结
通过定义抽象请求参数类和具体的请求参数类，并结合Spring Validation框架，可以实现对不同类型的报告生成需求，进行灵活且可扩展的参数验证。这种方案避免了修改核心接口，提高了代码的健壮性和可维护性。同时，使用javax.validation.Validator接口可以进行手动验证，更加灵活地控制验证流程。
注意事项:
- 在实际应用中，可能需要根据具体的业务需求，调整DTO的结构和验证逻辑。
- 可以使用BeanUtils.copyProperties()方法进行DTO之间的转换，但需要注意类型转换和空指针异常。
- 可以考虑使用分组验证，针对不同的场景，应用不同的验证规则。
希望本文能够帮助你更好地理解和应用Spring Validation框架，解决实际开发中的问题。
