获取map第一个的key和value_谁要是再敢用Map传参，我过去就是一JIO
還記得上次我寫過一篇關(guān)于實際項目代碼分層和規(guī)劃的文章《看完這篇，別人的開源項目結(jié)構(gòu)應(yīng)該能看懂了》， 在文尾處提到過一些注意事項，其中第一條就是：
- Contorller層參數(shù)傳遞建議不要使用HashMap，推薦使用數(shù)據(jù)模型定義
私信里竟然有很多小伙伴提問說，為什么不能這樣做？
我心里暗自尋思：難道這么做的小伙伴都沒有被同事捶嗎？(滑稽)
得嘞，今天咱們就掰扯掰扯這件事，這是實際寫代碼時常忽略的一個問題
是不是有人也這么寫過？
我自己曾經(jīng)接手過一個前人留下來的老項目，拿到代碼，導(dǎo)入IDEA的那一刻，我哭出了聲。
因為它的Controller層代碼都是類似這樣寫的：
@RestController@RequestMapping("/index")
public?class?IndexController?{
????//?獲取App首頁內(nèi)容
????@PostMapping("/getIndexContent")
????public?ResponseWrapper?getIndexContent(?@RequestBody?Map?paramMap?)?{
????????ResponseWrapper?res?=?new?ResponseWrapper();
????????//?下面開始做傳參有效性的校驗
????????if?(!paramMap.containsKey("article_id"))?{
????????????res.setCode(500);
????????????res.setMsg("缺少?article_id?信息");
????????????return?res;
????????}
????????if?(!paramMap.containsKey("page"))?{
????????????res.setCode(500);
????????????res.setMsg("缺少?page?信息");
????????????return?res;
????????}
????????if?(!paramMap.containsKey("size"))?{
????????????res.setCode(500);
????????????res.setMsg("缺少?size?信息");
????????????return?res;
????????}
????????if?(!paramMap.containsKey("version"))?{
????????????res.setCode(500);
????????????res.setMsg("缺少?version?信息");
????????????return?res;
????????}
????????//?......?此處省略
????}
????//?......?此處省略
}
別的咱先不說，居然明目張膽地在Controller層里方法里用Map傳參？！簡直喪心病狂了。幸虧下面還有一波傳參有效性的驗證，對于傳遞的參數(shù)，我好歹也能猜個大概，不然那真是喵了個咪了。
接下來，我們就好好嘮一嘮：為什么不要在Controller層傳參時使用Map類型！
Map一時爽，維護爽歪歪
正好，這地方有一個咱小伙伴活生生的例子。
前段時間，有個小伙伴跟我提問交流，說他接手了一個別人的老項目，問了我一個類似這樣的問題：
看到?jīng)]！
用Map傳參的第一個(也是最大的一個)弊端就是：這會導(dǎo)致后續(xù)接手和維護的人懷疑自己的人生，因為他根本不知道代碼傳的啥參數(shù)，想要構(gòu)造參數(shù)去調(diào)試接口只能靠腦補、摸瞎、以及猜測了。
試想一下，其實我們代碼里任何一個地方的傳參都可以使用Map來傳，如果真的這么做了，代碼中連任何數(shù)據(jù)模型類都不需要定義了，果真如此的話，這樣的代碼咱能看懂嗎？
而且這位小伙伴接手的項目居然還用的是LinkedHashMap參數(shù)，可以說很秀了。
除此之外，緊接著還會帶來下面這個問題。
好用的API工具與你無緣了
我之前寫過一篇文章《前后端都分離了，該搞個好用的API管理系統(tǒng)了！》，聊過現(xiàn)在市面上一些比較好用的、能極大提升前后端開發(fā)效率的API管理工具，這對于前后端開發(fā)來說，簡直是莫大的福音。
我們就以Swagger這個API工具為例，如果Controller傳參使用Map的話：
//?獲取App首頁內(nèi)容@ApiOperation("獲取App首頁內(nèi)容")
@PostMapping("/getIndexContent")
public?ResponseWrapper?getIndexContent(?@RequestBody?Map?paramMap?)?{
????//?......?此處省略
}
則API工具無法讀取具體參數(shù)項目和參數(shù)類型，所以傳參什么的也看不出來：
換言之，我如果將上面的Map傳參改為自定義數(shù)據(jù)模型類IndexQueryDto來傳參的話：
//?獲取App首頁內(nèi)容@ApiOperation("獲取App首頁內(nèi)容(改造后)")
@PostMapping("/getIndexContent")
public?ResponseWrapper?getIndexContent(?@RequestBody?IndexQueryDto?indexQueryDto?)?{
????//?......?此處省略
}@ApiModel(value?=?"App首頁內(nèi)容請求參數(shù)實體對象")
class?IndexQueryDto?{
????@ApiModelProperty(value?=?"文章ID號")
????@NotNull(message?=?"缺少?article_id?信息")
????private?Long?article_id;
????@ApiModelProperty(value?=?"頁面數(shù)")
????@NotNull(message?=?"缺少?page?信息")
????private?Integer?page;
????@ApiModelProperty(value?=?"每頁條目數(shù)")
????@NotNull(message?=?"缺少?size?信息")
????private?Integer?size;
????@ApiModelProperty(value?=?"App版本號")
????@NotNull(message?=?"缺少?version?信息")
????private?String?version;
????//?......?此處省略set/get方法
}
則類似Swagger這種API工具就非常方便地能幫助我們管理參數(shù)了：
這樣不管是自己調(diào)試，還是前、后端對接口都會方便得多。
同理，除了Swagger這種API管理工具之外，像在我的前文《沒用過這些IDEA插件？怪不得寫代碼頭疼》中推薦過的一個非常好用的接口管理插件RestfulToolkit也無法識別出Map類型所盛放的具體參數(shù)：
但是對于數(shù)據(jù)模型的定義參數(shù)，就能非常清晰的給出參數(shù)細節(jié)，并方便地提供接口測試：
優(yōu)秀的注解沒法使用了
還是以文章開頭舉例的代碼來說，不管怎么樣，寫這段代碼的哥們還是負責的，畢竟兢兢業(yè)業(yè)地用手工連環(huán)if()判斷完成了所有參數(shù)的有效性校驗：
但問題是，我們真的需要這種辣眼睛的手工連環(huán)if()判斷來做參數(shù)校驗嗎？
同樣在前文《啥？聽說你還在手寫復(fù)雜的參數(shù)校驗？》中也說過了，我們其實可以通過注解來方便地規(guī)避繁雜的參數(shù)校驗工作，但前提是不能使用Map類型傳參，需要使用數(shù)據(jù)模型的定義，就像這樣：
class?IndexQueryDto?{????@NotNull(message?=?"缺少?article_id?信息")
????private?Long?article_id;
????@NotNull(message?=?"缺少?page?信息")
????private?Integer?page;
????@NotNull(message?=?"缺少?size?信息")
????private?Integer?size;
????@NotNull(message?=?"缺少?version?信息")
????private?String?version;
????//?......?此處省略get/set方法
}
一個NotNull注解即可搞定，它不香嗎？
Map傳參真的一無是處嗎？
有些小伙伴表示用Map傳參的好處就是可以隨意擴展，后期變動靈活，想往里面塞幾個參數(shù)就塞幾個參數(shù)；而且也省去了各種對象定義和命名的煩惱。
如果非要用Map傳參
如果實在不能避免用Map傳參，也麻請配備完備的測試用例吧，省得讓后來接手維護的人天天看著代碼懷疑人生了。
通過測試用例，后來接手維護的人也能快速搞清代碼間的參數(shù)傳遞和調(diào)用，不然真的只能靠腦補畫面去調(diào)試了。
噓...
好了，說了這么多，如果你項目的`Controller層代碼還在使用HashMap傳參的話，答應(yīng)我，二話別說，趕快全部偷偷去改掉，快！速度！跑步前進！
每天進步一點點，Peace！
2020.04.02晚
給個[在看]，是對程序羊最大的支持總結(jié)
以上是生活随笔為你收集整理的获取map第一个的key和value_谁要是再敢用Map传参，我过去就是一JIO的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python多线程的作用_Python多
- 下一篇： 耳机使用说明书 jbl ua_用过JBL