在 java 應用的資料庫開發中，不可避免地會使用到持久層框架，而現在開源專案中持久層框架用到最多的基本就是 iBatis、myBatis 和 Hibernate 了。這裡就重點分析下這三個框架之間的區別。

iBatis 與 Hibernate
  iBatis 是基於SQL對映的持久層框架，相對 Hibernate 一站工的ORM解決框架來言，iBatis 算是一種半自動化的ORM實現。兩者的區別是：

• 
  1.Hibernate 是當前最流行、最經典的o/r mapping框架；而 iBatis 相對 Hibernate“o/r”而言是一種“sql mapping”的orm實現。
  2.iBatis入門簡單，即學即用；而Hibernate則相對來說較為複雜，學習門檻不低，要精通門檻更高，而且怎麼設計O/R對映，在效能和物件模型之間如何權衡取得平衡，怎樣用好 Hibernate 方面需要經驗和能力都很強才行。
  3.對於具體的資料操作，Hibernate 會自動生成sql 語句，能夠在程式執行時自動生成,能夠自動建表，無論到什麼機器上，都不需要資料庫，都能自動完成遷移；而iBatis 則要求開發者編寫具體的sql 語句，且必須要有相應的資料庫表才能進行資料庫的移植。相對 Hibernate 而言，iBatis 以sql開發的工作量和資料庫移植性上的讓步，為系統設計提供了更大的自由空間。
  4.Hibernate 功能強大，資料庫無關性好，O/R（物件/關係）對映能力強,Hibernate 對資料庫結構提供了較為完整的封裝，Hibernate 的O/R Mapping實現了POJO（實體類） 和資料庫表之間的對映，以及SQL 的自動生成和執行。程式設計師往往只需定義好了POJO 到資料庫表的對映關係，即可通過 Hibernate 提供的方法完成持久層操作。程式設計師甚至不需要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的儲存邏輯，自動生成對應的SQL 並呼叫JDBC 介面加以執行；而 iBatis 的著力點，則在於pojo與sql之間的對映關係。也就是說，iBatis 並不會為程式設計師在執行期自動生成sql 執行。具體的sql需要程式設計師編寫，然後通過對映配置檔案，將sql所需的引數，以及返回的結果欄位對映到指定pojo。使用 iBatis 提供的orm機制，對業務邏輯實現人員而言，面對的是純粹的java物件，缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了資料繫結程式碼，但是整個底層資料庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應快速資料庫修改。如果涉及到資料庫欄位的修改，Hibernate 修改的地方很少，而 iBatis 要把那些sql mapping的地方一一修改。
  5.當系統屬於二次開發,無法對資料庫結構做到控制和修改,那 iBatis 的靈活性將比 Hibernate 更適合。系統資料處理量巨大，效能要求極為苛刻，這往往意味著我們必須通過經過高度優化的SQL語句（或儲存過程）才能達到系統性能設計指標。在這種情況下 iBatis 會有更好的可控性和表現。
  6.Hibernate 現在已經是主流O/R Mapping框架，從文件的豐富性，產品的完善性，版本的開發速度都要強於iBatis。
  

iBatis與myBatis
  iBatis是2002年發起的開放原始碼專案，之前一直託管在apache下，於2010年6月16號被谷歌託管，改名為MyBatis，myBatis 與 iBatis 一樣，也是一種“半自動化”的ORM實現，共同的優點：

• 
  1.是一個基於Java的持久層框架
  2.提供的持久層框架包括SQL Maps和Data Access Objects（DAO）
  3.支援普通 SQL查詢，儲存過程和高階對映的優秀持久層框架
  4.消除了幾乎所有的JDBC程式碼和引數的手工設定以及結果集的檢索
  5.使用簡單的 XML或註解用於配置和原始對映，將介面和 Java 的POJOs（Plain Old Java Objects，普通的 Java物件）對映成資料庫中的記錄
  

總體流程：

• 
  1.載入配置並初始化
  2.接收呼叫請求
  3.處理操作請求
  4.返回處理結果將最終的處理結果返回
  

功能架構：

• 
  1.API介面層：提供給外部使用的介面API，開發人員通過這些本地API來操縱資料庫。介面層一接收到呼叫請求就會呼叫資料處理層來完成具體的資料處理。
  2.資料處理層：負責具體的SQL查詢、SQL解析、SQL執行和執行結果對映處理等。它主要的目的是根據呼叫的請求完成一次資料庫操作。
  3.基礎支撐層：負責最基礎的功能支撐，包括連線管理、事務管理、配置載入和快取處理，這些都是共用的東西，將他們抽取出來作為最基礎的元件。為上層的資料處理層提供最基礎的支撐。
  

當然，iBatis 改名為 myBatis 後，進行了一部分的改良，myBatis 在很多地方都藉助於 JDK 的泛型和註解特性進行了簡化，他們的主要區別是：

• 
  1.mybatis 實現了介面繫結，使用更加方便。在 iBatis 中我們需要在DAO的實現類中指定具體對應哪個xml對映檔案。簡單地講，就是 myBatis 不需要寫DAO介面的實現類了，已經自動實現了介面與xml對映檔案的對應。
  2.物件關係對映的改進，效率更高。myBatis中，除了相容 iBatis2.x 中的“巢狀查詢”方式外，還提供了直接“巢狀結果”的方式，其效果相當於直接通過一句sql將查詢出的dto物件自動封裝成所需的物件，但這一方式在使用分頁的時候並不起作用，或者說巢狀物件的結果集是不允許進行分頁的。
  3.個別配置的方法更改。iBatis 習慣把全域性配置檔案命名為 sqlMapConfig.xml， myBatis 將該檔案命名為 Configuration.xml 。iBatis 僅是以 SQL 對映為核心的框架，而在 myBatis 中多以 Mapper、Session、Configuration 等其他常用 ORM 框架中的名字代替，體現的無非是兩個方面：首先是為了減少開發者在切換框架所帶來的學習成本；其次，myBatis 充分吸收了其他 ORM 框架好的實踐，myBatis 現在已不僅僅是一個 SQL 對映框架了。在 iBatis 中，namespace 不是必需的，且它的存在沒有實際的意義。在 myBatis 中，namespace 終於派上用場了，它使得對映檔案與介面繫結變得非常自然。
  4.myBatis 採用功能強大的基於OGNL的表示式來消除其他元素。