本文轉自：http://www.cnblogs.com/waliwaliwa/p/6924849.html

今天換專案組了，給的專案，我看到mybatis框架寫的sql語句時，有點懵逼。。很久沒有用這種寫法了。就是接收引數和返回值都是用map

而我之前所接觸的專案都是將引數和返回值，對映到實體類上面的，

然後就很不解。去網上搜了一下。想找找兩者的區別，然後就找到了這篇文章，寫的挺不錯的，

MyBatis作為現近JavaEE企業級專案開發中常用的持久層框架之一，以其簡潔高效的ORM對映和高度的SQL的自由性被廣大開發人員認可。Mybatis在接收系統傳來的引數和返回的引數時主要可以有Map型別和實體型別兩種。在我參與開發的有限幾個專案當中，有使用實體型別比較多的，也有使用Map型別比較多的。不管選擇哪種型別，在專案架構來說決定了這個專案中部分請求和返回資料的型別。

 使用Map作為接收型別時，通常能夠在傳參到持久層這一過程中省去很多麻煩。前端請求及引數到達Action或者Controller時通常使用map來進行接收，使用map作為傳遞型別可以不用再將資料封裝為Bean型別再去根據實體屬性一一填充，直接通過Service和Dao以map型別將資料傳到map配置SQL檔案當中，省去很多資料轉換環節。再執行完SQL語句返回時制定map型別返回，不管是單條資料還是List都可以快速編寫並返回給前端。這種方式在處理多表查詢時避免了編寫大量的實體類和屬性欄位定義，減少了很多中間流程。缺點也一樣明顯，由於這種完全摒棄了面向物件思想的傳值型別，首先需要自己詳細記好map中key-value對映的關係，尤其的記好自己給每個資料庫欄位所定義的key值以做中間過程的檢視或修改。其次，當你的程式碼不止你一個維護時，你的同事並不能通過檢視實體類來獲知你這個業務所傳遞的具體欄位，只有通過詢問或檢視Map檔案或者除錯才能知曉，也不利於自己後期的codeReview。

使用實體類Bean來作為引數的傳遞型別，麻煩之處在於實體類的編寫以及大量的get、set方法，以及需要在map檔案中手寫大量關係對映。除此之外在設計多表多欄位的查詢和操作時往往需要大量的程式碼編寫已經多個程式碼層的變動，使得程式碼變得十分繁瑣。優點之處是在於使用了面向物件的思想，使得你的程式碼更容易讀懂。