問題描述

我在項目中經(jīng)常使用List<Map<String,Object>>做為查詢的接受對象.感覺使用方便,不用每個多表查詢的時候都創(chuàng)建DTO類.

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

問題解答

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

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

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

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

5、面相對象，將sql層與實體分離，降低耦合。否則維護很麻煩

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

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

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

Map<String, Object> 類型不安全

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

如果我沒有理解錯誤的話.

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

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

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

map的優(yōu)點：

1、靈活性強于javabean，易擴展，耦合度低。2、寫起來簡單，代碼量少。

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

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

權(quán)衡利弊，如果團隊開發(fā)還是javabean比較好，個人項目就無所謂了。歡迎補充！~