問(wèn)題描述

我在項(xiàng)目中經(jīng)常使用List<Map<String,Object>>做為查詢(xún)的接受對(duì)象.感覺(jué)使用方便,不用每個(gè)多表查詢(xún)的時(shí)候都創(chuàng)建DTO類(lèi).

上面只針對(duì)查詢(xún),如果將map應(yīng)用到DTO,VO是否會(huì)有相同的問(wèn)題.

問(wèn)題解答

1、map參數(shù)數(shù)量大時(shí)不易維護(hù)。要通過(guò)識(shí)別字符串形式的key，可能哪個(gè)字母沒(méi)加程序就出錯(cuò)了

2、map轉(zhuǎn)成實(shí)體，耗費(fèi)資源。或者不轉(zhuǎn)實(shí)體，直接將map傳到sql層，但要判斷空值（傳沒(méi)傳這個(gè)參數(shù)啊。。。），參數(shù)數(shù)量一多要加一堆判斷（sql效率下降，也不易維護(hù)）

3、創(chuàng)建map再put進(jìn)參數(shù)值，比創(chuàng)建一個(gè)實(shí)體類(lèi)的時(shí)間要長(zhǎng)（map數(shù)量少時(shí)創(chuàng)建的時(shí)間差距很小，但是數(shù)量較大時(shí)差距會(huì)非常大）

4、參數(shù)類(lèi)型的控制。sql中不是字符串類(lèi)型的參數(shù)還要轉(zhuǎn)成數(shù)值。。。錯(cuò)誤跑到sql中，容易被CC

5、面相對(duì)象，將sql層與實(shí)體分離，降低耦合。否則維護(hù)很麻煩

我認(rèn)為有兩個(gè)方面吧：1.面向?qū)ο蟮乃枷?.效率吧，畢竟玩查詢(xún)的【這里的效率是指map.get(key)】,map.put然后get的 這樣很容易出錯(cuò)吧， 的確不怎么好

都是我瞎編的，呵呵，大學(xué)老師好像講過(guò)吧。。

不利于他人共同開(kāi)發(fā)和后期維護(hù)

Map<String, Object> 類(lèi)型不安全

Map用查詢(xún)參數(shù)，方法調(diào)用者根本就不知道方法提供者提供方法參數(shù)可以存哪些健值對(duì)以及健值對(duì)類(lèi)型，map.put(key,value)亂傳的問(wèn)題不能在編譯階段發(fā)現(xiàn)，用QueryDto可以精確定義參數(shù)類(lèi)型和限制(JSR 303 Validation)

如果我沒(méi)有理解錯(cuò)誤的話(huà).

數(shù)據(jù)查詢(xún)對(duì)象是指 dao 查詢(xún)方法的參數(shù)封裝, 并不是指方法的返回. 這樣做的好處是代碼的可讀性高, 你直接使用map作為接口參數(shù), 使用者想要確定具體的查詢(xún)條件非常困難, 而且給外部接口調(diào)用的靈活性太高, 比如 使用者在map中增加一個(gè)x, 但是你的查詢(xún)根本不支持, 但是你如何讓使用者能夠確認(rèn)的知道呢?

而 dao 的返回參數(shù)按照文檔的要求是應(yīng)該使用 do/dto.

感覺(jué)主要是調(diào)試和維護(hù)困難，比如任何key的拼寫(xiě)錯(cuò)誤，要到query執(zhí)行時(shí)才能反饋

map的優(yōu)點(diǎn)：

1、靈活性強(qiáng)于javabean，易擴(kuò)展，耦合度低。2、寫(xiě)起來(lái)簡(jiǎn)單，代碼量少。

看一看Javabean的優(yōu)點(diǎn)：

1、面向?qū)ο蟮牧己迷忈尅?、數(shù)據(jù)結(jié)構(gòu)清晰，便于團(tuán)隊(duì)開(kāi)發(fā) & 后期維護(hù)。3、代碼足夠健壯，可以排除掉編譯期錯(cuò)誤。

權(quán)衡利弊，如果團(tuán)隊(duì)開(kāi)發(fā)還是javabean比較好，個(gè)人項(xiàng)目就無(wú)所謂了。歡迎補(bǔ)充！~