問題描述

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

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

問題解答

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

2、map轉成實體，耗費資源?；蛘卟晦D實體，直接將map傳到sql層，但要判斷空值（傳沒傳這個參數啊。。。），參數數量一多要加一堆判斷（sql效率下降，也不易維護）

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

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

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

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

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

不利于他人共同開發和后期維護

Map<String, Object> 類型不安全

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

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

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

而 dao 的返回參數按照文檔的要求是應該使用 do/dto.

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

map的優點：

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

看一看Javabean的優點：

1、面向對象的良好詮釋、2、數據結構清晰，便于團隊開發 & 后期維護。3、代碼足夠健壯，可以排除掉編譯期錯誤。

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