天天看點

SpringBoot2 參數管理實踐,入參出參與校驗

但是在日常開發中,礙于很多客觀因素,很少有時間去不斷思考和優化代碼,是以隻能從實際情況的角度去思考如何建構系統代碼,保證以後自己還能讀懂自己的代碼,在自己的幾年程式設計中,實際會考慮如下幾個方面:代碼層級

在程式設計系統中,為了能寫出良好的代碼,會根據是各種設計模式、原則、限制等去規範代碼,進而提高代碼的可讀性、複用性、可修改,實際上個人覺得,如果寫出的代碼很好,即别人修改也無法破壞原作者的思路和封裝,這應該是非常高水準。

但是在日常開發中,礙于很多客觀因素,很少有時間去不斷思考和優化代碼,是以隻能從實際情況的角度去思考如何建構系統代碼,保證以後自己還能讀懂自己的代碼,在自己的幾年程式設計中,實際會考慮如下幾個方面:代碼層級管理,命名和注釋統一,合理的設計業務資料庫,明确參數風格。

這裡就來聊一下參數管理,圍繞:入參、校驗、返參三個方面内容。

如何了解代碼規範這個概念:即大多數開發認同,願意遵守的限制,例如Spring架構和Mvc模式對于工程的管理,《Java開發手冊》中對于業務開發的規定,其根本目的都是想避免随着業務發展,代碼演變到無法維護的境界。

接收參數方式有很多種,List,Map,Object等等,但是為了明确參數的語義,通常都需要設計參數對象的結構并且遵守一定的規範,例如明确禁止Map接收參數:

Rest風格接收單個ID參數:

接收多個指定的參數:

基于Java包裝對象入參:

以上是在開發中常用的幾種接參方式,這裡通常會遵守下面幾個習慣:

參數語義:明确接收參數的作用;

個數限制:參數超過三個使用包裝對象;

避免多個接口使用單個包裝對象入參;

避免包裝對象主體過于複雜;

參數接收并沒有很複雜的限制,整體上也比較容易遵守,通常的問題在于處理較大主體對象時,容易産生一個包裝對象被多處複用,進而導緻對象字段屬性很多,這種情況在複雜業務中尤其容易出現,這種對象并不利于web層接口使用,或者很多時候都會在業務層和接口層混用對象;

在業務層封裝複雜的BO對象來降低業務管理的複雜度,這是合理常見的操作,可以在web接口層面根據接口功能各自管理入參主體,在業務實作的過程中,再傳入BO對象中。

避免複雜的業務包裝對象在各個層亂飄,如果多個接口入參都是同一個複雜的對象,很容易讓開發人員迷茫。

與參數接收相對應的就是參數響應,參數響應通常具有明确的限制規範:響應主體資料,響應碼,描述資訊。通常來說就是這樣三個核心要素。

響應參數主體:

這裡泛型的使用通常用來做主體資料的接收。

Code狀态碼

即接口狀态,建議參照并遵守<code>HttpStatus</code>中狀态碼的描述,這是開發普遍遵守的規範,如果不滿足業務需求,在适當自定義部分編碼,可以完全自定義一套響應碼,但是沒太多必要。

Msg描述

描述接口的響應的Msg可能就是:成功或失敗,更多的時候是需要處理業務異常的提示資訊,例如單号不存在,賬号當機等等,通常需要從業務異常中捕獲提示資訊,并響應頁面,或者入參校驗不通過的描述。

Data資料

接口響應的主體資料,不同的業務響應的對象肯定不同,是以這裡基于泛型機制接收即可,再以JSON格式響應頁面。

參考案例

接口返參:

響應格式:

參數接收和響應相對都不是複雜的,比較難處理的就是參數校驗:入參限制校驗,業務合法性校驗,響應參數非空非null校驗,等各種場景。

在系統運作過程中,任何參數都不是絕對可靠的,是以參數校驗随處可見,不同場景下的參數校驗,都有其必要性,但其根本目的都是為了給到請求端提示資訊,快速打斷流程,快速響應。

很多封裝思想,設計模式,或者這裡說的參數校驗,都可以參考現有Java源碼或者優秀的架構,這是一個應該具備的基礎意識。

Java原生方法之<code>java.lang.Thread</code>線程:

在Java源碼中,大部分都是采用原生的if判斷方式,對參數執行校驗

Spring架構之<code>org.springframework.util.ClassUtils</code>工具類部分代碼:

在Spring架構中除了基礎的if判斷之外,還封裝一個<code>org.springframework.util.Assert</code>斷言工具類。

If判斷

這種判斷在代碼中很常見,隻是一旦遇到校驗的主體對象很大,并且在分布式的環境中,需要重複寫if判斷的話,容易出錯是一個方面,對開發人員的耐心考驗是另一個方面。

Valid元件

在早幾年的時候,比較流行的常用校驗元件<code>Hibernate-Validator</code>,後來興起的<code>Validation-Api</code>,據說是參考前者實作,不過這并不重要,二者都簡化了對JavaBean的校驗機制。

基于注解的方式,标記Java對象的字段屬性,并設定如果校驗失敗的提示資訊。

校驗結果列印:

接口使用:

這種校驗機制基于注解方式,可以大幅度簡化普通的入參校驗,但是對業務參數的合法校驗并不适應,例如常見的ID不存在,狀态攔截等。

Assert斷言

關于Assert斷言方式,起初是在單元測試中常見,後來在各種優秀的架構中開始常見,例如Spring、Mybatis等,然後就開始出現在業務代碼中:

Assert斷言,可以替換傳統的if判斷,大量減少參數校驗的代碼行數,提高程式的可讀性,這種風格是目前比較流行的方式。

SpringBoot2 參數管理實踐,入參出參與校驗

閱讀标簽

【Java基礎】【設計模式】【結構與算法】【Linux系統】【資料庫】

【分布式架構】【微服務】【大資料元件】【SpringBoot進階】【Spring&amp;Boot基礎】

【資料分析】【技術導圖】【 職場】