來源：https://juejin.cn/post/7123091045071454238
一個優秀的 Controller 層邏輯
說到 Controller，相信大家都不陌生，它可以很方便地對外提供資料介面，它的定位，我認為是「不可或缺的配角」，
說它不可或缺是因為無論是傳統的三層架構還是現在的 COLA 架構，Controller 層依舊有一席之地，說明他的必要性，
說它是配角是因為 Controller 層的代碼一般是不負責具體的邏輯業務邏輯實作，但是它負責接收和回應請求，
從現狀看問題
Controller 主要的作業有以下幾項：
- 接收請求并決議引數
- 呼叫 Service 執行具體的業務代碼（可能包含引數校驗）
- 捕獲業務邏輯例外做出反饋
- 業務邏輯執行成功做出回應
//DTO
@Data
public class TestDTO {
private Integer num;
private String type;
}
//Service
@Service
public class TestService {
public Double service(TestDTO testDTO) throws Exception {
if (testDTO.getNum() <= 0) {
throw new Exception("輸入的數字需要大于0");
}
if (testDTO.getType().equals("square")) {
return Math.pow(testDTO.getNum(), 2);
}
if (testDTO.getType().equals("factorial")) {
double result = 1;
int num = testDTO.getNum();
while (num > 1) {
result = result * num;
num -= 1;
}
return result;
}
throw new Exception("未識別的演算法");
}
}
//Controller
@RestController
public class TestController {
private TestService testService;
@PostMapping("/test")
public Double test(@RequestBody TestDTO testDTO) {
try {
Double result = this.testService.service(testDTO);
return result;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
@Autowired
public DTOid setTestService(TestService testService) {
this.testService = testService;
}
}
如果真的按照上面所列的作業項來開發 Controller 代碼會有幾個問題：
- 引數校驗過多地耦合了業務代碼，違背單一職責原則
- 可能在多個業務中都拋出同一個例外，導致代碼重復
- 各種例外反饋和成功回應格式不統一，介面對接不友好
改造 Controller 層邏輯
統一回傳結構
統一回傳值型別無論專案前后端是否分離都是非常必要的，方便對接介面的開發人員更加清晰地知道這個介面的呼叫是否成功（不能僅僅簡單地看回傳值是否為 null 就判斷成功與否，因為有些介面的設計就是如此），
推薦一個開源免費的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
使用一個狀態碼、狀態資訊就能清楚地了解介面呼叫情況：
//定義回傳資料結構
public interface IResult {
Integer getCode();
String getMessage();
}
//常用結果的列舉
public enum ResultEnum implements IResult {
SUCCESS(2001, "介面呼叫成功"),
VALIDATE_FAILED(2002, "引數校驗失敗"),
COMMON_FAILED(2003, "介面呼叫失敗"),
FORBIDDEN(2004, "沒有權限訪問資源");
private Integer code;
private String message;
//省略get、set方法和構造方法
}
//統一回傳資料結構
@Data
@NoArgsConstructor
@AllArgsConstructor
public class Result<T> {
private Integer code;
private String message;
private T data;
public static <T> Result<T> success(T data) {
return new Result<>(ResultEnum.SUCCESS.getCode(), ResultEnum.SUCCESS.getMessage(), data);
}
public static <T> Result<T> success(String message, T data) {
return new Result<>(ResultEnum.SUCCESS.getCode(), message, data);
}
public static Result<?> failed() {
return new Result<>(ResultEnum.COMMON_FAILED.getCode(), ResultEnum.COMMON_FAILED.getMessage(), null);
}
public static Result<?> failed(String message) {
return new Result<>(ResultEnum.COMMON_FAILED.getCode(), message, null);
}
public static Result<?> failed(IResult errorResult) {
return new Result<>(errorResult.getCode(), errorResult.getMessage(), null);
}
public static <T> Result<T> instance(Integer code, String message, T data) {
Result<T> result = new Result<>();
result.setCode(code);
result.setMessage(message);
result.setData(data);
return result;
}
}
統一回傳結構后，在 Controller 中就可以使用了，但是每一個 Controller 都寫這么一段最終封裝的邏輯，這些都是很重復的作業，所以還要繼續想辦法進一步處理統一回傳結構，
統一包裝處理
Spring 中提供了一個類 ResponseBodyAdvice ，能幫助我們實作上述需求：
public interface ResponseBodyAdvice<T> {
boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> converterType);
@Nullable
T beforeBodyWrite(@Nullable T body, MethodParameter returnType, MediaType selectedContentType, Class<? extends HttpMessageConverter<?>> selectedConverterType, ServerHttpRequest request, ServerHttpResponse response);
}
ResponseBodyAdvice 是對 Controller 回傳的內容在 HttpMessageConverter 進行型別轉換之前攔截，進行相應的處理操作后，再將結果回傳給客戶端，
那這樣就可以把統一包裝的作業放到這個類里面：
- supports： 判斷是否要交給 beforeBodyWrite 方法執行，ture：需要；false：不需要
- beforeBodyWrite： 對 response 進行具體的處理
// 如果引入了swagger或knife4j的檔案生成組件，這里需要僅掃描自己專案的包，否則檔案無法正常生成
@RestControllerAdvice(basePackages = "com.example.demo")
public class ResponseAdvice implements ResponseBodyAdvice<Object> {
@Override
public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> converterType) {
// 如果不需要進行封裝的，可以添加一些校驗手段，比如添加標記排除的注解
return true;
}
@Override
public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType selectedContentType, Class<? extends HttpMessageConverter<?>> selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) {
// 提供一定的靈活度，如果body已經被包裝了，就不進行包裝
if (body instanceof Result) {
return body;
}
return Result.success(body);
}
}
經過這樣改造，既能實作對 Controller 回傳的資料進行統一包裝，又不需要對原有代碼進行大量的改動，
引數校驗
Java API 的規范 JSR303 定義了校驗的標準 validation-api ，其中一個比較出名的實作是 hibernate validation，
spring validation 是對其的二次封裝，常用于 SpringMVC 的引數自動校驗，引數校驗的代碼就不需要再與業務邏輯代碼進行耦合了，
①@PathVariable 和 @RequestParam 引數校驗
Get 請求的引數接收一般依賴這兩個注解，但是處于 url 有長度限制和代碼的可維護性，超過 5 個引數盡量用物體來傳參，
對 @PathVariable 和 @RequestParam 引數進行校驗需要在入參宣告約束的注解，
如果校驗失敗，會拋出 MethodArgumentNotValidException 例外，
@RestController(value = "https://www.cnblogs.com/javastack/archive/2022/12/19/prettyTestController")
@RequestMapping("/pretty")
public class TestController {
private TestService testService;
@GetMapping("/{num}")
public Integer detail(@PathVariable("num") @Min(1) @Max(20) Integer num) {
return num * num;
}
@GetMapping("/getByEmail")
public TestDTO getByAccount(@RequestParam @NotBlank @Email String email) {
TestDTO testDTO = new TestDTO();
testDTO.setEmail(email);
return testDTO;
}
@Autowired
public void setTestService(TestService prettyTestService) {
this.testService = prettyTestService;
}
}
校驗原理
在 SpringMVC 中，有一個類是 RequestResponseBodyMethodProcessor，這個類有兩個作用（實際上可以從名字上得到一點啟發）
- 用于決議 @RequestBody 標注的引數
- 處理 @ResponseBody 標注方法的回傳值
決議 @RequestBoyd 標注引數的方法是 resolveArgument，
public class RequestResponseBodyMethodProcessor extends AbstractMessageConverterMethodProcessor {
/**
* Throws MethodArgumentNotValidException if validation fails.
* @throws HttpMessageNotReadableException if {@link RequestBody#required()}
* is {@code true} and there is no body content or if there is no suitable
* converter to read the content with.
*/
@Override
public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
parameter = parameter.nestedIfOptional();
//把請求資料封裝成標注的DTO物件
Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
String name = Conventions.getVariableNameForParameter(parameter);
if (binderFactory != null) {
WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
if (arg != null) {
//執行資料校驗
validateIfApplicable(binder, parameter);
//如果校驗不通過，就拋出MethodArgumentNotValidException例外
//如果我們不自己捕獲，那么最侄訓由DefaultHandlerExceptionResolver捕獲處理
if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
}
}
if (mavContainer != null) {
mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
}
}
return adaptArgumentIfNecessary(arg, parameter);
}
}
public abstract class AbstractMessageConverterMethodArgumentResolver implements HandlerMethodArgumentResolver {
/**
* Validate the binding target if applicable.
* <p>The default implementation checks for {@code @javax.validation.Valid},
* Spring's {@link org.springframework.validation.annotation.Validated},
* and custom annotations whose name starts with "Valid".
* @param binder the DataBinder to be used
* @param parameter the method parameter descriptor
* @since 4.1.5
* @see #isBindExceptionRequired
*/
protected void validateIfApplicable(WebDataBinder binder, MethodParameter parameter) {
//獲取引數上的所有注解
Annotation[] annotations = parameter.getParameterAnnotations();
for (Annotation ann : annotations) {
//如果注解中包含了@Valid、@Validated或者是名字以Valid開頭的注解就進行引數校驗
Object[] validationHints = ValidationAnnotationUtils.determineValidationHints(ann);
if (validationHints != null) {
//實際校驗邏輯，最侄訓呼叫Hibernate Validator執行真正的校驗
//所以Spring Validation是對Hibernate Validation的二次封裝
binder.validate(validationHints);
break;
}
}
}
}
②@RequestBody 引數校驗
Post、Put 請求的引數推薦使用 @RequestBody 請求體引數，
對 @RequestBody 引數進行校驗需要在 DTO 物件中加入校驗條件后，再搭配 @Validated 即可完成自動校驗，
如果校驗失敗，會拋出 ConstraintViolationException 例外，
//DTO
@Data
public class TestDTO {
@NotBlank
private String userName;
@NotBlank
@Length(min = 6, max = 20)
private String password;
@NotNull
@Email
private String email;
}
//Controller
@RestController(value = "https://www.cnblogs.com/javastack/archive/2022/12/19/prettyTestController")
@RequestMapping("/pretty")
public class TestController {
private TestService testService;
@PostMapping("/test-validation")
public void testValidation(@RequestBody @Validated TestDTO testDTO) {
this.testService.save(testDTO);
}
@Autowired
public void setTestService(TestService testService) {
this.testService = testService;
}
}
校驗原理
宣告約束的方式，注解加到了引數上面，可以比較容易猜測到是使用了 AOP 對方法進行增強，
而實際上 Spring 也是通過 MethodValidationPostProcessor 動態注冊 AOP 切面，然后使用 MethodValidationInterceptor 對切點方法進行織入增強，
public class MethodValidationPostProcessor extends AbstractBeanFactoryAwareAdvisingPostProcessor implements InitializingBean {
//指定了創建切面的Bean的注解
private Class<? extends Annotation> validatedAnnotationType = Validated.class;
@Override
public void afterPropertiesSet() {
//為所有@Validated標注的Bean創建切面
Pointcut pointcut = new AnnotationMatchingPointcut(this.validatedAnnotationType, true);
//創建Advisor進行增強
this.advisor = new DefaultPointcutAdvisor(pointcut, createMethodValidationAdvice(this.validator));
}
//創建Advice，本質就是一個方法攔截器
protected Advice createMethodValidationAdvice(@Nullable Validator validator) {
return (validator != null ? new MethodValidationInterceptor(validator) : new MethodValidationInterceptor());
}
}
public class MethodValidationInterceptor implements MethodInterceptor {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
//無需增強的方法，直接跳過
if (isFactoryBeanMetadataMethod(invocation.getMethod())) {
return invocation.proceed();
}
Class<?>[] groups = determineValidationGroups(invocation);
ExecutableValidator execVal = this.validator.forExecutables();
Method methodToValidate = invocation.getMethod();
Set<ConstraintViolation<Object>> result;
try {
//方法入參校驗，最侄訓是委托給Hibernate Validator來校驗
//所以Spring Validation是對Hibernate Validation的二次封裝
result = execVal.validateParameters(
invocation.getThis(), methodToValidate, invocation.getArguments(), groups);
}
catch (IllegalArgumentException ex) {
...
}
//校驗不通過拋出ConstraintViolationException例外
if (!result.isEmpty()) {
throw new ConstraintViolationException(result);
}
//Controller方法呼叫
Object returnValue = https://www.cnblogs.com/javastack/archive/2022/12/19/invocation.proceed();
//下面是對回傳值做校驗，流程和上面大概一樣
result = execVal.validateReturnValue(invocation.getThis(), methodToValidate, returnValue, groups);
if (!result.isEmpty()) {
throw new ConstraintViolationException(result);
}
return returnValue;
}
}
③自定義校驗規則
有些時候 JSR303 標準中提供的校驗規則不滿足復雜的業務需求，也可以自定義校驗規則，
自定義校驗規則需要做兩件事情：
- 自定義注解類，定義錯誤資訊和一些其他需要的內容
- 注解校驗器，定義判定規則
//自定義注解類
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Constraint(validatedBy = MobileValidator.class)
public @interface Mobile {
/**
* 是否允許為空
*/
boolean required() default true;
/**
* 校驗不通過回傳的提示資訊
*/
String message() default "不是一個手機號碼格式";
/**
* Constraint要求的屬性，用于分組校驗和擴展，留空就好
*/
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
//注解校驗器
public class MobileValidator implements ConstraintValidator<Mobile, CharSequence> {
private boolean required = false;
private final Pattern pattern = Pattern.compile("^1[34578][0-9]{9}$"); // 驗證手機號
/**
* 在驗證開始前呼叫注解里的方法，從而獲取到一些注解里的引數
*
* @param constraintAnnotation annotation instance for a given constraint declaration
*/
@Override
public void initialize(Mobile constraintAnnotation) {
this.required = constraintAnnotation.required();
}
/**
* 判斷引數是否合法
*
* @param value object to validate
* @param context context in which the constraint is evaluated
*/
@Override
public boolean isValid(CharSequence value, ConstraintValidatorContext context) {
if (this.required) {
// 驗證
return isMobile(value);
}
if (StringUtils.hasText(value)) {
// 驗證
return isMobile(value);
}
return true;
}
private boolean isMobile(final CharSequence str) {
Matcher m = pattern.matcher(str);
return m.matches();
}
}
自動校驗引數真的是一項非常必要、非常有意義的作業，JSR303 提供了豐富的引數校驗規則，再加上復雜業務的自定義校驗規則，完全把引數校驗和業務邏輯解耦開，代碼更加簡潔，符合單一職責原則，
自定義例外與統一攔截例外
原來的代碼中可以看到有幾個問題：
- 拋出的例外不夠具體，只是簡單地把錯誤資訊放到了 Exception 中
- 拋出例外后，Controller 不能具體地根據例外做出反饋
- 雖然做了引數自動校驗，但是例外回傳結構和正常回傳結構不一致
自定義例外是為了后面統一攔截例外時，對業務中的例外有更加細顆粒度的區分，攔截時針對不同的例外作出不同的回應，
而統一攔截例外的目的一個是為了可以與前面定義下來的統一包裝回傳結構能對應上，另一個是我們希望無論系統發生什么例外，Http 的狀態碼都要是 200 ，盡可能由業務來區分系統的例外，
//自定義例外
public class ForbiddenException extends RuntimeException {
public ForbiddenException(String message) {
super(message);
}
}
//自定義例外
public class BusinessException extends RuntimeException {
public BusinessException(String message) {
super(message);
}
}
//統一攔截例外
@RestControllerAdvice(basePackages = "com.example.demo")
public class ExceptionAdvice {
/**
* 捕獲 {@code BusinessException} 例外
*/
@ExceptionHandler({BusinessException.class})
public Result<?> handleBusinessException(BusinessException ex) {
return Result.failed(ex.getMessage());
}
/**
* 捕獲 {@code ForbiddenException} 例外
*/
@ExceptionHandler({ForbiddenException.class})
public Result<?> handleForbiddenException(ForbiddenException ex) {
return Result.failed(ResultEnum.FORBIDDEN);
}
/**
* {@code @RequestBody} 引數校驗不通過時拋出的例外處理
*/
@ExceptionHandler({MethodArgumentNotValidException.class})
public Result<?> handleMethodArgumentNotValidException(MethodArgumentNotValidException ex) {
BindingResult bindingResult = ex.getBindingResult();
StringBuilder sb = new StringBuilder("校驗失敗:");
for (FieldError fieldError : bindingResult.getFieldErrors()) {
sb.append(fieldError.getField()).append("：").append(fieldError.getDefaultMessage()).append(", ");
}
String msg = sb.toString();
if (StringUtils.hasText(msg)) {
return Result.failed(ResultEnum.VALIDATE_FAILED.getCode(), msg);
}
return Result.failed(ResultEnum.VALIDATE_FAILED);
}
/**
* {@code @PathVariable} 和 {@code @RequestParam} 引數校驗不通過時拋出的例外處理
*/
@ExceptionHandler({ConstraintViolationException.class})
public Result<?> handleConstraintViolationException(ConstraintViolationException ex) {
if (StringUtils.hasText(ex.getMessage())) {
return Result.failed(ResultEnum.VALIDATE_FAILED.getCode(), ex.getMessage());
}
return Result.failed(ResultEnum.VALIDATE_FAILED);
}
/**
* 頂級例外捕獲并統一處理，當其他例外無法處理時候選擇使用
*/
@ExceptionHandler({Exception.class})
public Result<?> handle(Exception ex) {
return Result.failed(ex.getMessage());
}
}
總結
做好了這一切改動后，可以發現 Controller 的代碼變得非常簡潔，可以很清楚地知道每一個引數、每一個 DTO 的校驗規則，可以很明確地看到每一個 Controller 方法回傳的是什么資料，也可以方便每一個例外應該如何進行反饋，
這一套操作下來后，我們能更加專注于業務邏輯的開發，代碼簡介、功能完善，何樂而不為呢？
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/540270.html
標籤：其他