目錄一、參數(shù)管理二、接收參數(shù)三、響應(yīng)參數(shù)四、參數(shù)校驗(yàn)1、借鑒參考2、常用校驗(yàn)方式五、源代碼地址一、參數(shù)管理

在編程系統(tǒng)中，為了能寫出良好的代碼，會(huì)根據(jù)是各種設(shè)計(jì)模式、原則、約束等去規(guī)范代碼，從而提高代碼的可讀性、復(fù)用性、可修改，實(shí)際上個(gè)人覺(jué)得，如果寫出的代碼很好，即別人修改也無(wú)法破壞原作者的思路和封裝，這應(yīng)該是非常高水準(zhǔn)。

但是在日常開發(fā)中，礙于很多客觀因素，很少有時(shí)間去不斷思考和優(yōu)化代碼，所以只能從實(shí)際情況的角度去思考如何構(gòu)建系統(tǒng)代碼，保證以后自己還能讀懂自己的代碼，在自己的幾年編程中，實(shí)際會(huì)考慮如下幾個(gè)方面：代碼層級(jí)管理，命名和注釋統(tǒng)一，合理的設(shè)計(jì)業(yè)務(wù)數(shù)據(jù)庫(kù)，明確參數(shù)風(fēng)格。

這里就來(lái)聊一下參數(shù)管理，圍繞：入?yún)ⅰ⑿ｒ?yàn)、返參三個(gè)方面內(nèi)容。

如何理解代碼規(guī)范這個(gè)概念：即大多數(shù)開發(fā)認(rèn)同，愿意遵守的約束，例如Spring框架和Mvc模式對(duì)于工程的管理，《Java開發(fā)手冊(cè)》中對(duì)于業(yè)務(wù)開發(fā)的規(guī)定，其根本目的都是想避免隨著業(yè)務(wù)發(fā)展，代碼演變到無(wú)法維護(hù)的境界。

二、接收參數(shù)

接收參數(shù)方式有很多種，List，Map，Object等等，但是為了明確參數(shù)的語(yǔ)義，通常都需要設(shè)計(jì)參數(shù)對(duì)象的結(jié)構(gòu)并且遵守一定的規(guī)范，例如明確禁止Map接收參數(shù)：

Rest風(fēng)格接收單個(gè)ID參數(shù)：

@GetMapping('/param/single/{id}')public String paramSingle (@PathVariable Integer id){ return 'Resp:'+id ;}

接收多個(gè)指定的參數(shù)：

@GetMapping('/param/multi')public String paramMulti (@RequestParam('key') String key, @RequestParam('var') String var){ return 'Resp:'+key+var ;}

基于Java包裝對(duì)象入?yún)ⅲ?/p>

@PostMapping('/param/wrap')public ParamIn paramWrap (@RequestBody ParamIn paramIn){ return paramIn ;}-- 參數(shù)對(duì)象實(shí)體public class ParamIn { private Integer id ; private String key ; private String var ; private String name ;}

以上是在開發(fā)中常用的幾種接參方式，這里通常會(huì)遵守下面幾個(gè)習(xí)慣：

參數(shù)語(yǔ)義：明確接收參數(shù)的作用； 個(gè)數(shù)限制：參數(shù)超過(guò)三個(gè)使用包裝對(duì)象； 避免多個(gè)接口使用單個(gè)包裝對(duì)象入?yún)ⅲ? 避免包裝對(duì)象主體過(guò)于復(fù)雜；

參數(shù)接收并沒(méi)有很復(fù)雜的約束，整體上也比較容易遵守，通常的問(wèn)題在于處理較大主體對(duì)象時(shí)，容易產(chǎn)生一個(gè)包裝對(duì)象被多處復(fù)用，進(jìn)而導(dǎo)致對(duì)象字段屬性很多，這種情況在復(fù)雜業(yè)務(wù)中尤其容易出現(xiàn)，這種對(duì)象并不利于web層接口使用，或者很多時(shí)候都會(huì)在業(yè)務(wù)層和接口層混用對(duì)象；

在業(yè)務(wù)層封裝復(fù)雜的BO對(duì)象來(lái)降低業(yè)務(wù)管理的復(fù)雜度，這是合理常見的操作，可以在web接口層面根據(jù)接口功能各自管理入?yún)⒅黧w，在業(yè)務(wù)實(shí)現(xiàn)的過(guò)程中，再傳入BO對(duì)象中。

避免復(fù)雜的業(yè)務(wù)包裝對(duì)象在各個(gè)層亂飄，如果多個(gè)接口入?yún)⒍际峭粋€(gè)復(fù)雜的對(duì)象，很容易讓開發(fā)人員迷茫。

三、響應(yīng)參數(shù)

與參數(shù)接收相對(duì)應(yīng)的就是參數(shù)響應(yīng)，參數(shù)響應(yīng)通常具有明確的約束規(guī)范：響應(yīng)主體數(shù)據(jù)，響應(yīng)碼，描述信息。通常來(lái)說(shuō)就是這樣三個(gè)核心要素。

響應(yīng)參數(shù)主體：

這里泛型的使用通常用來(lái)做主體數(shù)據(jù)的接收。

public class Resp<T> { private int code ; private String msg ; private T data ; public static <T> Resp<T> ok (T data) {Resp<T> result = new Resp<>(HttpStatus.OK);result.setData(data);return result ; } public Resp (HttpStatus httpStatus) {this.code = httpStatus.value();this.msg = httpStatus.getReasonPhrase(); } public Resp(int code, String msg, T data) {this.code = code;this.msg = msg;this.data = data; }}

Code狀態(tài)碼

即接口狀態(tài)，建議參照并遵守HttpStatus中狀態(tài)碼的描述，這是開發(fā)普遍遵守的規(guī)范，如果不滿足業(yè)務(wù)需求，在適當(dāng)自定義部分編碼，可以完全自定義一套響應(yīng)碼，但是沒(méi)太多必要。

Msg描述

描述接口的響應(yīng)的Msg可能就是：成功或失敗，更多的時(shí)候是需要處理業(yè)務(wù)異常的提示信息，例如單號(hào)不存在，賬號(hào)凍結(jié)等等，通常需要從業(yè)務(wù)異常中捕獲提示信息，并響應(yīng)頁(yè)面，或者入?yún)⑿ｒ?yàn)不通過(guò)的描述。

Data數(shù)據(jù)

接口響應(yīng)的主體數(shù)據(jù)，不同的業(yè)務(wù)響應(yīng)的對(duì)象肯定不同，所以這里基于泛型機(jī)制接收即可，再以JSON格式響應(yīng)頁(yè)面。

參考案例

接口返參：

@PostMapping('/resp/wrap')public Resp<KeyValue> respWrap (@RequestBody KeyValue keyValue){ return Resp.ok(keyValue) ;}

響應(yīng)格式：

{ 'code': 200, 'msg': 'OK', 'data': { 'key': 'hello', 'value': 'world' }}四、參數(shù)校驗(yàn)

參數(shù)接收和響應(yīng)相對(duì)都不是復(fù)雜的，比較難處理的就是參數(shù)校驗(yàn)：入?yún)⒓s束校驗(yàn)，業(yè)務(wù)合法性校驗(yàn)，響應(yīng)參數(shù)非空非null校驗(yàn)，等各種場(chǎng)景。

在系統(tǒng)運(yùn)行過(guò)程中，任何參數(shù)都不是絕對(duì)可靠的，所以參數(shù)校驗(yàn)隨處可見，不同場(chǎng)景下的參數(shù)校驗(yàn)，都有其必要性，但其根本目的都是為了給到請(qǐng)求端提示信息，快速打斷流程，快速響應(yīng)。

1、借鑒參考

很多封裝思想，設(shè)計(jì)模式，或者這里說(shuō)的參數(shù)校驗(yàn)，都可以參考現(xiàn)有Java源碼或者優(yōu)秀的框架，這是一個(gè)應(yīng)該具備的基礎(chǔ)意識(shí)。

Java原生方法之java.lang.Thread線程:

public void interrupt() { if (this != Thread.currentThread())checkAccess(); synchronized (blockerLock) {Interruptible b = blocker;if (b != null) { interrupt0(); b.interrupt(this); return;} } interrupt0();}

在Java源碼中，大部分都是采用原生的if判斷方式，對(duì)參數(shù)執(zhí)行校驗(yàn)

Spring框架之org.springframework.util.ClassUtils工具類部分代碼：

public static Class<?> forName(String name, @Nullable ClassLoader classLoader)throws ClassNotFoundException, LinkageError {Assert.notNull(name, 'Name must not be null');Class<?> clazz = resolvePrimitiveClassName(name);if (clazz == null) {clazz = commonClassCache.get(name);}if (clazz != null) {return clazz;}}

在Spring框架中除了基礎(chǔ)的if判斷之外，還封裝一個(gè)org.springframework.util.Assert斷言工具類。

2、常用校驗(yàn)方式

If判斷

@GetMapping('/check/base')public String baseCheck (@RequestParam('var') String var){ if (var == null) {return var+' is null' ; } if (''.equals(var)){return var+' is empty' ; } if ('hello'.equals(var)){return var+' sensitive word ' ; } return var + ' through ' ;}

這種判斷在代碼中很常見，只是一旦遇到校驗(yàn)的主體對(duì)象很大，并且在分布式的環(huán)境中，需要重復(fù)寫if判斷的話，容易出錯(cuò)是一個(gè)方面，對(duì)開發(fā)人員的耐心考驗(yàn)是另一個(gè)方面。

Valid組件

在早幾年的時(shí)候，比較流行的常用校驗(yàn)組件Hibernate-Validator，后來(lái)興起的Validation-Api，據(jù)說(shuō)是參考前者實(shí)現(xiàn)，不過(guò)這并不重要，二者都簡(jiǎn)化了對(duì)JavaBean的校驗(yàn)機(jī)制。

基于注解的方式，標(biāo)記Java對(duì)象的字段屬性，并設(shè)定如果校驗(yàn)失敗的提示信息。

public class JavaValid { @NotNull(message='ID不能為空') private Integer id ; @Email(message='郵箱格式異常') private String email ; @NotEmpty(message = '字段不能為空') @Size(min = 2,max = 10,message = '字段長(zhǎng)度不合理') private String data ;}

校驗(yàn)結(jié)果打印：

public class JavaValidTest { private static Validator validator ; @BeforeClass public static void beforeBuild (){validator = Validation.buildDefaultValidatorFactory().getValidator(); } @Test public void checkValid (){JavaValid valid = new JavaValid(null,'email','data') ;Set<ConstraintViolation<JavaValid>> validateInfo = validator.validate(valid) ;// 打印校驗(yàn)結(jié)果validateInfo.stream().forEach(validObj -> { System.out.println('validateInfo：'+validObj.getMessage());}); }}

接口使用：

@PostMapping('/java/valid')public JavaValid javaValid (@RequestBody @Valid JavaValid javaValid,BindingResult errorMsg){ if (errorMsg.hasErrors()){List<ObjectError> objectErrors = errorMsg.getAllErrors() ;objectErrors.stream().forEach(objectError -> { logger.info('CheckRes:{}',objectError.getDefaultMessage());}); } return javaValid ;}

這種校驗(yàn)機(jī)制基于注解方式，可以大幅度簡(jiǎn)化普通的入?yún)⑿ｒ?yàn)，但是對(duì)業(yè)務(wù)參數(shù)的合法校驗(yàn)并不適應(yīng)，例如常見的ID不存在，狀態(tài)攔截等。

Assert斷言

關(guān)于Assert斷言方式，起初是在單元測(cè)試中常見，后來(lái)在各種優(yōu)秀的框架中開始常見，例如Spring、Mybatis等，然后就開始出現(xiàn)在業(yè)務(wù)代碼中：

public class AssertTest { private String varObject ; @Before public void before (){varObject = RandomUtil.randomString(6) ; } @Test public void testEquals (){Assert.assertEquals(varObject+'不匹配',varObject,RandomUtil.randomString(6)); } @Test public void testEmpty (){Assert.assertTrue(StrUtil.isNotEmpty(varObject));Assert.assertFalse(varObject+' not empty',StrUtil.isNotEmpty(varObject)); } @Test public void testArray (){/* 數(shù)組元素不相等: arrays first differed at element [1]; Expected :u08 Actual :mwm */String var = RandomUtil.randomString(5) ;String[] arrOne = new String[]{var,RandomUtil.randomString(3)} ;String[] arrTwo = new String[]{var,RandomUtil.randomString(3)} ;Assert.assertArrayEquals('數(shù)組元素不相等',arrOne,arrTwo); }}

Assert斷言，可以替換傳統(tǒng)的if判斷，大量減少參數(shù)校驗(yàn)的代碼行數(shù)，提高程序的可讀性，這種風(fēng)格是目前比較流行的方式。

五、源代碼地址

GitHub·地址https://github.com/cicadasmile/middle-ware-parentGitEE·

地址https://gitee.com/cicadasmile/middle-ware-parent

以上就是SpringBoot2 參數(shù)管理實(shí)踐，入?yún)⒊鰠⑴c校驗(yàn)的詳細(xì)內(nèi)容，更多關(guān)于SpringBoot2 參數(shù)校驗(yàn)的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！