讓我們來總結一下使用傳統JDBC操作資料需要經過哪幾個步驟：

1. 使用JDBC程式設計需要連線資料庫，註冊驅動和資料庫資訊
2. 操作Connection，開啟 Statement 物件 。
3. 通過Statement執行SQL， 返回結果到ResultSet物件。
4. 使用ResultSet讀取資料，然後通過程式碼轉化為具體的POJO物件。
5. 關閉資料庫的相關資源。

那麼，如果我們還是繼續使用傳統的JDBC方式來操作資料庫會存在哪些弊端呢？

• 工作量相對較大。我們需要先連線，然後處理JDBC底層事務，處理資料型別。我們還需要操作Connection物件、Statement物件和ResultSet物件去拿到資料，並準確的關閉它們
• 我們要對JDBC程式設計可能產生的異常進行捕捉處理並正確關閉資源。

對於一個JDBC操作簡單的SQL尚且如止的複雜，何況是更為複雜的應用呢？所以這種模式很快的就被一些新 的方法所取代了。於是ORM就出現了。不過，我們要知道所有的ORM模型都是基於對JDBC的進行封裝，不同的ORM模型對JDBC封閉的強度是不一樣的。

那麼問題來了。什麼是ORM模型。ORM模型的作用是什麼 。為什麼要用ORM模型等一系列疑問。
由於JDBC存在的缺陷，所以我們在實際工作中很少使用JDBC進行操作資料庫的程式設計。於是我們就提出了物件關係對映（Object Relational Mapping）簡稱 ORM，或者O/RM，或者 O/R mapping。

什麼是ORM模型？
　　ORM模型就是資料庫的表和簡單Java物件（Plain Ordinary Java Object，簡稱POJO）的對映關係模型。
ORM模型的作用是什麼 ？
　　它主要解決資料庫資料和POJO物件的相互對映。我們通過這層對映就可以簡單的把資料庫表的資料轉化為POJO。以便程式設計師更加容易的理解和應用Java程式.而且程式設計師一般只需要瞭解Java應用而無需對資料庫進行深入的瞭解。此外，ORM模型提供了統一的規則使得資料庫的資料通過配置便可輕易的對映到POJO上。。

目前我們接觸到有Hibernate和MyBatis。
　　Hibernate　：本人在大學的時候學的就是這個框架。
　　
　優點：　　

1. 消除了程式碼的對映規則，它全部被分離到XML或者註解裡面去配置。
2. 無需再管理資料庫連線，它也配置到XML裡面。
3. 一個會話中，不要操作多個物件，只要操作Sesison即可。
4. 關閉資源只需要關閉一個Session即可。

缺點：

1. 全表對映帶來的不便，比如更新時需要傳送所有的欄位。
2. 無法根據不同的條件組裝不同的SQL。　
3. 對多表關聯和複雜的SQL查詢支援較差。需要自己寫SQL，返回後，需要自己將資料組裝到POJO中。
4. 不能有效支援儲存過程。
5. 雖然有HQL，但是效能較差，大型網際網路往往需要優化SQL，而Hibernate做不到。

MyBatis：
　是為了解決Hibernate的不足。一個關自動對映的框架MyBatis應運而生。之所以稱之為半自動。是國為它需要手動匹配提供POJO、SQL和對映關係。而全表的Hibernate只需要提供POJO和對映關係即可。

優點：

1. 易於上手和掌握。
2. sql寫在xml裡，便於統一管理和優化。
3. 解除sql與程式程式碼的耦合。
4. 提供對映標籤，支援物件與資料庫的orm欄位關係對映
5. 提供物件關係對映標籤，支援物件關係組建維護
6. 提供xml標籤，支援編寫動態sql。

缺點：

1. sql工作量很大，尤其是欄位多、關聯表多時，更是如此。
2. sql依賴於資料庫，導致資料庫移植性差。
3. 由於xml裡標籤id必須唯一，導致DAO中方法不支援方法過載。
4. 欄位對映標籤和物件關係對映標籤僅僅是對對映關係的描述，具體實現仍然依賴於sql。（比如配置了一對多Collection標籤，如果sql裡沒有join子表或查詢子表的話，查詢後返回的物件是不具備物件關係的，即Collection的物件為null）
5. DAO層過於簡單，物件組裝的工作量較大。
6. 不支援級聯更新、級聯刪除。
7. 編寫動態sql時,不方便除錯，尤其邏輯複雜時。
8. 提供的寫動態sql的xml標籤功能簡單（連struts都比不上），編寫動態sql仍然受限，且可讀性低。
9. 若不查詢主鍵欄位，容易造成查詢出的物件有“覆蓋”現象。
10. 引數的資料型別支援不完善。（如引數為Date型別時，容易報沒有get、set方法，需在引數上加@param）
11. 多引數時，使用不方便，功能不夠強大。（目前支援的方法有map、物件、註解@param以及預設採用012索引位的方式）
12. 快取使用不當，容易產生髒資料。
    　　

來，讓我們瞭解一下MyBatis的歷史。
　歷史上，MyBatis的前身是Apache的一個開源專案iBatis。2010年這個專案 由apache software foundation 遷移到了google code, 並且改名為MyBatis 。 2013年11 月遷移到GitHub，所以目前的MyBatis是GitHub進行維護的。
　iBatis 一詞是源於“Internet”和 “abatis” 的組合 ，是一個基於Java的持久層框架。iBatis 提供的持久層框架包括SQL Maps和DAO（Data Access Objects）。它能很好的解決Hibernate遇到的問題。與Hibernate不同的是，它不單單要我們提供對映檔案，還需要我們提供SQL語句。MyBatis需要提供對映檔案包含以下三個部分。

• SQL
• 對映規則
• POJO

什麼時候用MyBatis（MyBatis 的使用場景）。

　Hibernate作為較為流行的Java ORM框架，它確實程式設計簡易，需要我們提供對映的規則，完全可以通過IDE生成。同時無需編寫SQL確實開發效率優於MyBatis。而且，它也提供了快取、日誌、級聯、等強大的功能，但是Hibernate的缺陷也是十分的明顯的。就是在多表關聯複雜的SQL時，資料系統許可權限制時，根據條件變化的SQL時。儲存過程等使用場景。Hibernate十分不便。而效能又難以通過SQL來優化。所以Hibernate一般只適用於場景不太複雜的、效能要求不太苛刻的時候使用。

　MyBatis 是一個靈活的、可以動態生成對映關係的框架，它幾物可以替代JDBC。擁有動態列、動態表名，儲存過程都支援。同時提供了簡易的快取（如(預設)一級快取，還有二級快取）、日誌、級聯。但是它的缺陷是需要你提供對映規則和SQL，所以它的開發工作量一般要比Hibernate略大一些。

　　總結。你需要根據你的專案的實際情況去選擇框架。MyBatis具有高度靈活、可優化、易維護等特點，所以它目前是大型移動網際網路的自選框架。