業務層經常做的一些判斷：
public String addUser(User user) { if (user == null || user.getId() == null || user.getAccount() == null || user.getPassword() == null || user.getEmail() == null) { return "對象或者對象字段不能為空"; } if (StringUtils.isEmpty(user.getAccount()) || StringUtils.isEmpty(user.getPassword()) || StringUtils.isEmpty(user.getEmail())) { return "不能輸入空字符串"; } if (user.getAccount().length() < 6 || user.getAccount().length() > 11) { return "賬號長度必須是6-11個字符"; } if (user.getPassword().length() < 6 || user.getPassword().length() > 16) { return "密碼長度必須是6-16個字符"; } if (!Pattern.matches("^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\\.[a-zA-Z0-9_-]+)+$", user.getEmail())) { return "郵箱格式不正確"; } // 參數校驗完畢后這里就寫上業務邏輯 return "success"; }
Validator 可以非常方便的制定校驗規則，並自動幫你完成校驗。首先在入參里需要校驗的字段加上注解,每個注解對應不同的校驗規則，並可制定校驗失敗后的信息：
@Data public class User { @NotNull(message = "用戶id不能為空") private Long id; @NotNull(message = "用戶賬號不能為空") @Size(min = 6, max = 11, message = "賬號長度必須是6-11個字符") private String account; @NotNull(message = "用戶密碼不能為空") @Size(min = 6, max = 11, message = "密碼長度必須是6-16個字符") private String password; @NotNull(message = "用戶郵箱不能為空") @Email(message = "郵箱格式不正確") private String email; }
校驗規則和錯誤提示信息配置完畢后，接下來只需要在接口需要校驗的參數上加上 @Valid 注解，並添加 BindResult 參數即可方便完成驗證：
@RestController @RequestMapping("user") public class UserController { @Autowired private UserService userService; @PostMapping("/addUser") public String addUser(@RequestBody @Valid User user, BindingResult bindingResult) { // 如果有參數校驗失敗，會將錯誤信息封裝成對象組裝在BindingResult里 for (ObjectError error : bindingResult.getAllErrors()) { return error.getDefaultMessage(); } return userService.addUser(user); } }
這樣當請求數據傳遞到接口的時候 Validator 就自動完成校驗了，校驗的結果就會封裝到 BindingResult 中去，如果有錯誤信息我們就直接返回給前端，業務邏輯代碼也根本沒有執行下去。
此時，業務層里的校驗代碼就已經不需要了：
eg：
public String addUser(User user) { // 直接編寫業務邏輯 return "success"; }
現在可以看一下參數校驗效果。我們故意給這個接口傳遞一個不符合校驗規則的參數，先傳遞一個錯誤數據給接口，故意將 password這 個字段不滿足校驗條件：
{ "account": "12345678", "email": "123@qq.com", "id": 0, "password": "123" // 密碼規則為"密碼長度必須是6-16個字符" }
再來看一下接口的響應數據：
這樣是不是方便很多？不難看出使用 Validator 校驗有如下幾個好處：
-
簡化代碼，之前業務層那么一大段校驗代碼都被省略掉了；
-
使用方便，那么多校驗規則可以輕而易舉的實現，比如郵箱格式驗證，之前自己手寫正則表達式要寫那么一長串，還容易出錯，用 Validator 直接一個注解搞定（還有更多校驗規則注解，可以自行去了解哦）；
-
減少耦合度，使用 Validator 能夠讓業務層只關注業務邏輯，從基本的參數校驗邏輯中脫離出來。
使用 Validator + BindingResult 已經是非常方便實用的參數校驗方式了，在實際開發中也有很多項目就是這么做的，不過這樣還是不太方便，因為你每寫一個接口都要添加一個 BindingResult 參數，然后再提取錯誤信息返回給前端。
這樣有點麻煩，並且重復代碼很多（盡管可以將這個重復代碼封裝成方法）。我們能否去掉 BindingResult 這一步呢？當然是可以的！
Validator + 自動拋出異常
我們完全可以將 BindingResult 這一步給去掉：
@PostMapping("/addUser")
public String addUser(@RequestBody @Valid User user) {
return userService.addUser(user);
}
去掉之后會發生什么事情呢？直接來試驗一下，還是按照之前一樣故意傳遞一個不符合校驗規則的參數給接口。此時我們觀察控制台可以發現接口已經引發 MethodArgumentNotValidException 異常了，
控制台打印：
其實這樣就已經達到我們想要的效果了，參數校驗不通過自然就不執行接下來的業務邏輯，去掉 BindingResult 后會自動引發異常，異常發生了自然而然就不會執行業務邏輯。也就是說，我們完全沒必要添加相關 BindingResult 相關操作嘛。不過事情還沒有完，異常是引發了，可我們並沒有編寫返回錯誤信息的代碼呀，那參數校驗失敗了會響應什么數據給前端呢？我們來看一下剛才異常發生后接口響應的數據：
返回的信息直接將整個錯誤對象相關信息都響應給前端了！這樣就很難受，不過解決這個問題也很簡單，就是我們接下來要講的全局異常處理！
全局異常處理
參數校驗失敗會自動引發異常，我們當然不可能再去手動捕捉異常進行處理，不然還不如用之前 BindingResult 方式呢。又不想手動捕捉這個異常，又要對這個異常進行處理，那正好使用 SpringBoot 全局異常處理來達到一勞永逸的效果！
1、首先，我們需要新建一個類，在這個類上加上 @ControllerAdvice 或 @RestControllerAdvice 注解，這個類就配置成全局處理類了（這個根據你的 Controller 層用的是 @Controller 還是 @RestController 來決定）。
然后在類中新建方法，在方法上加上 @ExceptionHandler 注解並指定你想處理的異常類型。接着在方法內編寫對該異常的操作邏輯，就完成了對該異常的全局處理！我們現在就來演示一下對參數校驗失敗拋出的 MethodArgumentNotValidException 全局處理：
@RestControllerAdvice public class ExceptionControllerAdvice { @ExceptionHandler(MethodArgumentNotValidException.class) //==>指定異常 public String MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) { // 從異常對象中拿到ObjectError對象 ObjectError objectError = e.getBindingResult().getAllErrors().get(0); // 然后提取錯誤提示信息進行返回 return objectError.getDefaultMessage(); } }
校驗后：
{ "timestamp": 1596009721019, "status": 400, "error": "Bad Request", "errors": [ { "codes": [ "Size.user.password", "Size.password", "Size.java.lang.String", "Size" ], "arguments": [ { "codes": [ "user.password", "password" ], "arguments": null, "defaultMessage": "password", "code": "password" }, 11, 6 ], "defaultMessage": "密碼長度必須是6-16個字符", "objectName": "user", "field": "password", "rejectedValue": "123", "bindingFailure": false, "code": "Size" } ], "message": "Validation failed for object='user'. Error count: 1", "path": "/nfdw-szpj-5G/userMapper/addUser" }
只有密碼不合格，返回的就是我們制定的錯誤提示信息！我們通過全局異常處理優雅的實現了我們想要的功能！以后我們再想寫接口參數校驗，就只需要在入參的成員變量上加上 Validator 校驗規則注解，然后在參數上加上 @Valid 注解即可完成校驗，校驗失敗會自動返回錯誤提示信息，無需任何其他代碼！
自定義異常
全局處理當然不會只能處理一種異常，用途也不僅僅是對一個參數校驗方式進行優化。在實際開發中，如何對異常處理其實是一個很麻煩的事情。傳統處理異常一般有以下煩惱：
-
是捕獲異常 try...catch 還是拋出異常 throws？
-
是在 Controller 層做處理還是在 Service 層處理又或是在 DAO 層做處理？
-
處理異常的方式是啥也不做，還是返回特定數據？如果返回又返回什么數據？
-
不是所有異常我們都能預先進行捕捉，如果發生了沒有捕捉到的異常該怎么辦？
以上這些問題都可以用全局異常處理來解決，全局異常處理也叫統一異常處理，全局和統一處理代表什么？代表規范！規范有了，很多問題就會迎刃而解！全局異常處理的基本使用方式大家都已經知道了，我們接下來更進一步的規范項目中的異常處理方式：自定義異常。在很多情況下，我們需要手動拋出異常，比如在業務層當有些條件並不符合業務邏輯，我這時候就可以手動拋出異常從而觸發事務回滾。那手動拋出異常最簡單的方式就是 throw new RuntimeException("異常信息") 了，不過使用自定義會更好一些：
-
自定義異常可以攜帶更多的信息，不像這樣只能攜帶一個字符串；
-
項目開發中經常是很多人負責不同的模塊，使用自定義異常可以統一了對外異常展示的方式；
-
自定義異常語義更加清晰明了，一看就知道是項目中手動拋出的異常。
我們現在就來開始寫一個自定義異常：
/** * Created by Alex on 2020-07-29 */ @Getter //只要getter方法，無需setter public class APIException extends RuntimeException { private int code; private String msg; public APIException() { this(1001, "接口錯誤"); } public APIException(String msg) { this(1001, msg); } public APIException(int code, String msg) { super(msg); this.code = code; this.msg = msg; } }
在剛才的全局異常處理類中記得添加對我們自定義異常的處理：
// 自定義 @ExceptionHandler(APIException.class) public String APIExceptionHandler(APIException e) { return e.getMsg(); }
這樣就對異常的處理就比較規范了。當然還可以添加對 Exception 的處理，這樣無論發生什么異常我們都能屏蔽掉然后響應數據給前端。不過建議最后項目上線時這樣做，能夠屏蔽掉錯誤信息暴露給前端，在開發中為了方便調試還是不要這樣做。
現在全局異常處理和自定義異常已經弄好了，不知道大家有沒有發現一個問題，就是當我們拋出自定義異常的時候，全局異常處理只響應了異常中的錯誤信息 msg 給前端，並沒有將錯誤代碼 code 返回。這就要引申出我們接下來要講的東西了：數據統一響應。
數據統一響應
現在我們規范好了參數校驗方式和異常處理方式，然而還沒有規范響應數據！比如我要獲取一個分頁信息數據，獲取成功了呢自然就返回的數據列表；獲取失敗了后台就會響應異常信息，即一個字符串。就是說前端開發者壓根就不知道后端響應過來的數據會是啥樣的！所以，統一響應數據是前后端規范中必須要做的！
自定義統一響應體
統一數據響應，第一步肯定要做的就是我們自己自定義一個響應體類。無論后台是運行正常還是發生異常，響應給前端的數據格式是不變的！那么如何定義響應體呢？可以參考我們自定義異常類，也來一個響應信息代碼 code 和響應信息說明 msg：
@Getter public class ResultVO<T> { /** * 狀態碼，比如1000代表響應成功 */ private int code; /** * 響應信息，用來說明響應情況 */ private String msg; /** * 響應的具體數據 */ private T data; public ResultVO(T data) { this(1000, "success", data); } public ResultVO(int code, String msg, T data) { this.code = code; this.msg = msg; this.data = data; } }
修改一下全局異常處理那的返回值：
@RestControllerAdvice public class ExceptionControllerAdvice { // 全局異常 // @ExceptionHandler(MethodArgumentNotValidException.class) // public String MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) { // // 從異常對象中拿到ObjectError對象 // ObjectError objectError = e.getBindingResult().getAllErrors().get(0); // // 然后提取錯誤提示信息進行返回 // return objectError.getDefaultMessage(); // } // 自定義異常 @ExceptionHandler(APIException.class) public ResultVO<String> APIExceptionHandler(APIException e) { // 注意哦，這里返回類型是自定義響應體 return new ResultVO<>(e.getCode(), "響應失敗", e.getMsg()); } // 自定義全局異常 @ExceptionHandler(MethodArgumentNotValidException.class) public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) { ObjectError objectError = e.getBindingResult().getAllErrors().get(0); // 注意哦，這里返回類型是自定義響應體 return new ResultVO<>(1001, "參數校驗失敗", objectError.getDefaultMessage()); } }
此時如果發生異常了會響應什么數據給前端：
響應碼枚舉--規范code碼
@Getter public enum ResultCode { SUCCESS(1000, "操作成功"), FAILED(1001, "響應失敗"), VALIDATE_FAILED(1002, "參數校驗失敗"), ERROR(5000, "未知錯誤"); private int code; private String msg; ResultCode(int code, String msg) { this.code = code; this.msg = msg; } }
然后修改響應體的構造方法，讓其只准接受響應碼枚舉來設置響應碼和響應信息：
@Getter public class ResultVO<T> { public ResultVO(T data) { this(ResultCode.SUCCESS, data); } public ResultVO(ResultCode resultCode, T data) { this.code = resultCode.getCode(); this.msg = resultCode.getMsg(); this.data = data; } }
然后同時修改全局異常處理的響應碼設置方式：
// 自定義異常 @ExceptionHandler(APIException.class) public ResultVO<String> APIExceptionHandler(APIException e) { // 注意哦，這里傳遞的響應碼枚舉 return new ResultVO<>(ResultCode.FAILED, e.getMsg()); } @ExceptionHandler(MethodArgumentNotValidException.class) public ResultVO<String> MethodArgumentNotValidExceptionHandler(MethodArgumentNotValidException e) { ObjectError objectError = e.getBindingResult().getAllErrors().get(0); // 注意哦，這里傳遞的響應碼枚舉 return new ResultVO<>(ResultCode.VALIDATE_FAILED, objectError.getDefaultMessage()); }
這樣響應碼和響應信息只能是枚舉規定的那幾個，就真正做到了響應數據格式、響應碼和響應信息規范化、統一化！