隨著開發團隊轉投GoogleCode旗下，ibatis3.x正式更名為Mybatis 

對於從事 Java EE 的開發人員來說，iBatis 是一個再熟悉不過的持久層框架了，在Hibernate、JPA 這樣的一站式物件 / 關係對映（O/R Mapping）解決方案盛行之前，iBaits基本是持久層框架的不二選擇。即使在持久層框架層出不窮的今天，iBatis 憑藉著易學易用、輕巧靈活等特點，也仍然擁有一席之地。尤其對於擅長 SQL的開發人員來說，iBatis 對 SQL 和儲存過程的直接支援能夠讓他們在獲得 iBatis 封裝優勢的同時而不喪失 SQL 調優的手段，這是 Hibernate/JPA所無法比擬的。具體而言，使用 iBatis 框架的主要優勢主要體現在如下幾個方面：

首先，iBatis 封裝了絕大多數的 JDBC 樣板程式碼，使得開發者只需關注 SQL本身，而不需要花費精力去處理例如註冊驅動，建立 Connection，以及確保關閉 Connection 這樣繁雜的程式碼。

其次，iBatis可以算是在所有主流的持久層框架中學習成本最低，最容易上手和掌握的框架。雖說其他持久層框架也號稱門檻低，容易上手，但是等到你真正使用時會發現，要想掌握並用好它是一件非常困難的事。在工作中我需要經常參與面試，我曾聽到過很多位應聘者描述，他們所在的專案在技術選型時選擇Hibernate，後來發現難以駕馭，不得不將程式碼用 JDBC 或者 iBatis 改寫。

iBatis 自從在 Apache 軟體基金會網站上釋出至今，和他的明星兄弟們（HttpServer，Tomcat，Struts，Maven，Ant 等等）一起接受者萬千 Java 開發者的敬仰。然而在今年六月中旬，幾乎是釋出 3.0版本的同時，iBatis 主頁上的一則 “Apache iBATIS has been retired” 的宣告在社群引起了一陣不小的波瀾。在 Apache寄居六年之後，iBatis 將程式碼託管到 Google Code。在宣告中給出的主要理由是，和 Apache 相比，Google Code更有利於開發者的協同工作，也更能適應快速釋出。於此同時，iBatis 更名為 MyBatis。

從 iBatis 到 MyBatis，不只是名稱上的變化，MyBatis 提供了更為強大的功能，同時並沒有損失其易用性，相反，在很多地方都藉助於JDK 的泛型和註解特性進行了簡化。iBatis 確實該退休了，因為一個更為出色的繼任者經過 10 個 Beta 版本的蛻變已然出現在我們的面前。

兩者的具體變化讓我們細細說來：

一、全域性配置檔案：

根據 iBatis 的習慣，我們通常把全域性配置檔案命名為sqlMapConfig.xml，檔名本身並沒有要求，在 MyBatis 中，也經常會將該檔案命名為 Configuration.xml（讀完全文後讀者也許會發現，在 iBatis 中經常出現的 “sqlMap” 在 MyBatis 中被逐漸淡化了，除了此處，還比如 iBatis配置檔案的根元素為 <sqlMapConfig>，指定對映檔案的元素為 <sqlMap>，以及 SqlMapClient等等，這個變化正說明，iBatis 僅是以 SQL 對映為核心的框架，而在 MyBatis 中多以 Mapper、Session、Configuration等其他常用 ORM 框架中的名字代替，體現的無非是兩個方面：首先是為了減少開發者在切換框架所帶來的學習成本；其次，MyBatis 充分吸收了其他 ORM框架好的實踐，MyBatis 現在已不僅僅是一個 SQL 對映框架了）

在全域性配置檔案中可以配置的資訊主要包括如下幾個方面：

• properties ---用於提供一系列的鍵值對組成的屬性資訊，該屬性資訊可以用於整個配置檔案中。
• settings ---用於設定 MyBatis的執行時方式，比如是否啟用延遲載入等。
• typeAliases ---為 Java型別指定別名，可以在 XML檔案中用別名取代 Java類的全限定名。
• typeHandlers ---在 MyBatis通過 PreparedStatement為佔位符設定值，或者從 ResultSet取出值時，特定型別的型別處理器會被執行。
• objectFactory --- MyBatis通過 ObjectFactory來建立結果物件。可以通過繼承 DefaultObjectFactory來實現自己的 ObjectFactory類。
• plugins ---用於配置一系列攔截器，用於攔截對映 SQL語句的執行。可以通過實現 Interceptor介面來實現自己的攔截器。
• environments ---用於配置資料來源資訊，包括連線池、事務屬性等。
• mappers ---程式中所有用到的 SQL對映檔案都在這裡列出，這些對映 SQL都被 MyBatis管理。

清單 1.簡單的全域性配置檔案示例

<?xml version="1.0"encoding="UTF-8" ?>
 <!--iBatis 和 MyBatis 的全域性配置檔案使用不同的 DTD約束，在將應用由
 iBatis 升級至 MyBatis 時需要注意（兩者的對映檔案 DTD約束也不相同）-->
 <!DOCTYPE configuration PUBLIC"-//mybatis.org//DTD Config 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-config.dtd">
 <configuration>
 <!-- 配置資料來源相關的資訊 -->
 <environments default="demo">
 <environment id="demo">
 <transactionManagertype="JDBC"/>
 <dataSource type="POOLED">
 <property name="driver" value= …/>
 <property name="url" value= …/>
 <property name="username"value="root"/>
 <property name="password"value="root"/>
 </dataSource>
 </environment>
 </environments>
 <!-- 列出對映檔案 -->
 <mappers>
 <mapperresource="footmark/mybatis/demo/UserInfoMapper.xml"/>
 </mappers>
 </configuration>

有了這些資訊，MyBatis便能夠和資料庫建立連線，並應用給定的連線池資訊和事務屬性。MyBatis 封裝了這些操作，最終暴露一個 SqlSessionFactory例項供開發者使用，從名字可以看出來，這是一個建立 SqlSession 的工廠類，通過 SqlSession例項，開發者能夠直接進行業務邏輯的操作，而不需要重複編寫 JDBC 相關的樣板程式碼。根據全域性配置檔案生成 SqlSession 的程式碼如下：

 Reader reader =Resources.getResourceAsReader("Configuration.xml");
 SqlSessionFactory sqlSessionFactory =
 new SqlSessionFactoryBuilder().build(reader);
 SqlSession sqlSession =sqlSessionFactory.openSession();

可以把上面的三行程式碼看做是 MyBatis 建立SqlSession 的樣板程式碼。其中第一行程式碼在類路徑上載入配置檔案，Resources 是 MyBatis提供的一個工具類，它用於簡化資原始檔的載入，它可以訪問各種路徑的檔案，不過最常用的還是示例中這種基於類路徑的表示方式。

二、Mybatis實現了介面繫結，使用更加方便。

在ibatis2.x中我們需要在DAO的實現類中指定具體對應哪個xml對映檔案，

而Mybatis實現了DAO介面與xml對映檔案的繫結，自動為我們生成介面的具體實現，使用起來變得更加省事和方便。這可以說是Mybatis最重要的改進。

注意：

雖然Mybatis支援在介面中直接使用annotation的配置方式來簡化配置，不過強烈建議仍然使用xml配置的方式。畢竟annotation的配置方式功能有限且程式碼入侵性太強。使用xml配置方式才能體現出Mybatis的優勢所在。

三、MyBatis採用功能強大的基於OGNL的表示式來消除其他元素。

熟悉struts2的人應該對OGNL表示式不會感到陌生，MyBatis採用OGNL表示式簡化了配置檔案的複雜性，使用起來更簡潔。

四、動態sql

在配置動態sql語句方面，mybatis中使用的標籤與iBATIS中使用的標籤有很大的不同。這裡不再舉例。但這往往是你從iBATIS遷移到mybatis的過程中最為巨大的工作量。

五、。。。。。

       mybatis與iBATIS可以說有很多地方相同，但卻是有很多細節上的不同這裡就不一一列出了。還是希望讀者在具體的實戰中發掘。如果你原來沒有接觸過iBATIS，那你完全可以直接學習mybatis了。因為mybatis確實是在iBATIS上的改進與發展。

總結：

如果讀者對 Hibernate有所瞭解，一定會發現 MyBatis 不論是使用風格還是類名都和 Hibernate 非常相像，筆者曾今多次在國內外 Java 社群看到有人說 MyBatis在向 Hibernate/JPA靠攏。暫且不論這是否屬實，持久化技術在經過一番蓬勃的競爭和發展，最終在社群形成統一的認識並被廣泛接受，這對開發者而言未必不是一件好事，MyBatis在這一點上只是向事實上的標準靠近了一步。