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

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

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

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

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

我認為有兩個面向吧：
1.物件導向的想法
2.效率吧，畢竟玩查詢的【這裡的效率是指map.get(key)】,map.put然後get的這樣很容易出錯吧， 的確不怎麼好

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

不利於他人共同開發和後期維護

Map 類型不安全

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比較好，個人專案就無所謂了。
歡迎補充！ ~