程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

對於寫Java的程序員來說,不管是寫單純的接口、還是頁面後臺一把梭,後端參數校驗的功能都是整個代碼不可或缺的一部分,它可以從系統入口過濾掉一些不合法的數據,以確保我們的系統穩定。

還記得我剛入行Java寫後端那會兒,因為剛從Android端轉後端開發,對對端開發還不是很熟悉。有天我們架構師老大給了我一個需求、要寫一個接口給客戶端調用,功能其實挺簡單:就是根據客戶端傳過來的一些參數去數據庫查數據,再返回給客戶端。

我雖然作為一個後端萌新,但畢竟寫代碼的底子還在啊!很快我就完成了,自己測試一下完美通過,立刻提交代碼、並主動叫我們老大Code review,我心裡還指著我們老大能誇我一頓、說我寫得真快呢!

沒想到我們老大隻看了一眼就把我提交的代碼打回來了,我記得當時我的代碼差不多是這樣寫的:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

我自問寫的代碼沒問題,就找老大問他我的代碼沒問題怎麼給我打回來了?只見老大一臉無奈地看著我說:功能是沒問題,就是寫的太醜陋了點。好吧,我承認代碼寫的是長了點、亂了點,可那是因為接口參數太多,不得一個個校驗一下嗎?

說到這裡,老大微微一笑說:來,教你一招。只見老大手指上下翻飛,三兩下就我的校驗參數地代碼全刪完了,重構完地代碼瞬間清爽了許多:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

老大得意的對我說:看起來不錯吧?不要你晚上加個班熟悉一下Spring Validation機制吧?寶寶心裡苦啊!

下面我們就一起來看看Spring Validation怎麼使用吧。

首先添加POM依賴

新建一個Spring Boot項目,並在pom.xml文件添加依賴:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

需要特別注意的一點是:如果我們項目中引入了spring-boot-starter-web

依賴,那麼它會自動依賴spring-boot-starter-validation,無需我們再手動添加依賴,防止出現一些版本兼容的問題。

添加約束註解

在接收參數的UserReq實體類對應的屬性上加上約束註解:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

注意點:

  • 每個約束註解都有一個message
    元素,用於校驗失敗時的提示信息
  • 一個屬性可以添加多個約束註解,所有註解是與的關係,必須全部驗證通過
  • 可以使用正則表達式校驗參數

眼尖的同學可能會發現上面代碼中用到的一些約束註解一些是引用自javax.validation.constraints包下,還有一些引用自org.hibernate.validator.constraints包下,這是怎麼一回事呢?

說到這裡,不得不提一下JSR-303,JSR-303是JAVA EE(現改名為:Jakarta EE)中的一項子規範,叫Bean Validation,它定義了一些實體和方法驗證的約束和接口規範,而Hibernate Validator對Bean Validation規範中所有內置約束註解都提供了實現,並且還添加了一些額外的約束註解。

Bean Validation中內置的約束註解:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

Hibernate Validator中添加的約束註解:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

值得一提的是:在Hibernate Validator中額外添加的一些優秀的約束註解比如@Email、@NotEmpty、@NotBlank已經被吸收到Bean Validation標準約束註解中,所有我們在代碼中Import時應儘量使用javax.validation.constraints包下的約束註解。

怎麼使用呢?

接收參數的實體類我們已經改造好了,但是還不能實現校驗的功能,還需要對Controller進行改造:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

  • 在接收方法的參數前面加上@Validated註解,當然也可以加@Valid註解
  • 想要獲取參數校驗的結果,則需要進行校驗的參數後面緊跟一個BingingResult類型的參數,用來綁定校驗結果

關於第一點,@Validated註解由Spring框架提供,可以說是對JSR-303規範標準註解@Valid的封裝,可以提供額外的例如分組校驗的功能。實際上任何以"Valid"開頭的註解都可以實現同樣的效果(至於原因有機會專門寫一篇講一下,感興趣的可以關注一下)

至於第二點,為什麼校驗結果會自動綁定到後面緊跟的BingingResult對象,這裡面涉及到Spring DataBinder數據綁定相關的知識(以後會專門講解,感興趣的可以關注一下),現在我們只需要知道這樣寫就行。

請求測試

現在我們使用Postman工具來請求我們的接口:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

然後我們打上斷點來調試一下bindingResult對象:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

可以看到bindingResult對象成功綁定並返回了三個屬性校驗失敗的結果。

分組校驗

我們寫業務時通常會存在一種情況:新增操作時通常不需要校驗參數Id

,而在修改或刪除操作時我們又需要校驗參數Id,那麼對於同一個參數接收類UserReq,我們要怎麼處理呢?

很簡單,首先我們新建一個更新分組,只需要一個普普通通的接口類就行:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

接著我們在UserReq類裡新增一個id屬性,同時加上@NotNull分組校驗:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

groups支持傳入一個數組,可以傳入多個分組,對於id屬性來說,在更新和刪除操作時我們都需要校驗該屬性。

最後,在Controller裡更新接口方法中添加校驗分組:

程序員寫接口參數校驗,總是太多if else?一招讓你避免體力活

我們只需要在註解中加上需要校驗的Update分組就行啦。


我是一名程序員,喜歡我的文章歡迎 轉發 及 關注,我也會經常與大家分享工作當中的代碼那些事兒。


分享到:


相關文章: