對于從事 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 軟件基金會網站上發布至今，和他的明星兄弟們（Http Server，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 版本的蛻變已然出現在我們的面前。

本文將主要針對 MyBatis 和 iBatis 的變化之處進行討論，以便于讀者順利從 iBatis 向 MyBatis 過渡。

由一個??MyBatis??示例開始

　　如果讀者接觸過一些常用的 Java EE 框架，應該都知道這些框架需要提供一個全局配置文件，用于指定程序正常運行所需的設置和參數信息。而針對常用的持久層框架而言（Hibernate、JPA、iBatis 等），則通常需要配置兩類文件：一類用于指定數據源、事務屬性以及其他一些參數配置信息（通常是一個獨立的文件，可以稱之為全局配置文件）；另一類則用于指定數據庫表和程序之間的映射信息（可能不止一個文件，我們稱之為映射文件）。MyBatis 也不例外，雖然其中的一部分可以通過注解的形式進行，但是這兩部分內容本身仍是必不可少的。

　　根據 iBatis 的習慣，我們通常把全局配置文件命名為 sqlMapConfig.xml，文件名本身并沒有要求，在 MyBatis 中，也經常會將該文件命名為 Configuration.xml （讀完全文后讀者也許會發現，在 iBatis 中經常出現的 “sqlMap” 在 MyBatis 中被逐漸淡化了，除了此處，還比如 iBatis 配置文件的根元素為 ，指定映射文件的元素為 ，以及 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 管理。

上面提及的大多數元素都不是必需的，通常 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"> ?<transactionManager type="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> ?<mapper resource="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 提供的一個工具類，它用于簡化資源文件的加載，它可以訪問各種路徑的文件，不過最常用的還是示例中這種基于類路徑的表示方式。如果讀者對 Hibernate 有所了解，一定會發現 MyBatis 不論是使用風格還是類名都和 Hibernate 非常相像，筆者曾今多次在國內外 Java 社區看到有人說 MyBatis 在向 Hibernate/JPA 靠攏。暫且不論這是否屬實，持久化技術在經過一番蓬勃的競爭和發展，最終在社區形成統一的認識并被廣泛接受，這對開發者而言未必不是一件好事，MyBatis 在這一點上只是向事實上的標準靠近了一步。

在完成全局配置文件，并通過 MyBatis 獲得 SqlSession 對象之后，便可以執行數據訪問操作了。對于 iBatis/MyBatis 而言，要執行的操作其實就是在映射文件中配置的 SQL 語句。兩者的配置基本相同，如下所示：

清單??2.??在映射文件中配置??SQL??語句

??<?xml version="1.0" encoding="UTF-8" ?> ?<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> ?<mapper namespace="mybatis.demo.UserInfoMapper"> ?<select id="selectUser" parameterType="int" ?resultType="mybatis.demo.UserInfo"> ?select * from UserInfo where userid =#{userid} ?</select> ?</mapper>

　　在 iBatis 中，namespace 不是必需的，且它的存在沒有實際的意義。在 MyBatis 中，namespace 終于派上用場了，它使得映射文件與接口綁定變得非常自然。關于接口綁定，后面會有篇幅專門描述。使用 SqlSession 執行 SQL 的方式如下：

清單??3.??使用??SqlSession??執行映射文件中配置的??SQL??語句

??try ?{ ?UserInfo userinfo = (UserInfo) sqlSession.selectOne ?("mybatis.demo.UserInfoMapper.getUser", 2); ?System.out.println(userinfo); ?} finally ?{ ?sqlSession.close(); ?}

　　需要注意的是，SqlSession 的使用必需遵守上面的格式，即在 finally 塊中將其關閉。以保證資源得到釋放，防止出現內存泄露！

以上就是一個簡單而完整的 MyBatis 程序。其中涉及了全局配置文件，映射文件，構建 SqlSession 對象，執行數據訪問操作等四個步驟。下面將針對除構建 SqlSession 對象之外的三塊內容進行分解。

MyBatis??全局配置文件的改變

　　MyBatis 全局配置文件的各主要元素基本和 iBatis 相同，只是在用法和個別名稱上做了調整。元素的意義就不再描述，下面主要講述針對 iBatis 和 MyBatis 配置文件的主要區別之處。

首先，兩個版本的 DTD 約束不同，MyBatis 的 DTD 文件已經包含在發布包下的 mybatis-3.0.x.jar 包中。這直接影響到的是，iBatis 配置文件的根元素是 <sqlMapConfig>，而 MyBatis 使用的是 <configuration>。

其次，<settings> 的用法發生了改變，之前的格式為：

清單??4.??在??iBatis??中設置屬性的方式

?????<settings props1="value1" props2="value2"… />

要設置的屬性直接以鍵值對的形式作為 <settings> 的屬性。而在 MyBatis 中調整為略顯復雜但卻更有條理的方式：

清單??5.??在??MyBatis??中設置屬性的方式

???<settings> ?<setting name="props1" value="value1"/> ?<setting name="props2" value="value2"/> …… ?</settings>

另外，之前配置事務管理器和數據源的方式如下：

清單??6.??在??iBatis??中配置事務管理器和數據源的方式

??<transactionManager type="JDBC" > ?<dataSource type="SIMPLE"> ?<property name="JDBC.Driver" value="${driver}"/> ?<!-- 其他數據源信息省略 --> ?</dataSource> ?</transactionManager>

在 MyBatis 中調整為如下的方式：

清單??7.??在??MyBatis??中配置事務管理器和數據源的方式

?<environments default="demo"> ?<environment id="demo"> ?<transactionManager type="JDBC"/> ?<dataSource type="POOLED"> ?<property name="JDBC.Driver" value="${driver}"/> ?<!-- 其他數據源信息省略 --> ?</dataSource> ?</environment> ?</environments>

　　通過 <environments> 來進行數據源管理，主要是為了簡化在多套數據源配置之間的切換，比如開發和發布使用不同的配置。

最后，在 iBatis 中指定映射文件的方式如下：

清單??8.??在??iBatis??中指定映射文件的方式

??<sqlMap resource=... /> ?<sqlMap resource=... /> ?<sqlMap resource=... />

在 MyBatis 中調整為如下方式：

清單??9.??在??MyBatis??中指定映射文件的方式

???<mappers> ?<mapper resource=... /> ?<mapper resource=... /> ?</mappers>

　　上面的這些調整，主要出發點其實并不是使得 MyBatis 功能更為強大，而是使配置更為合理，讓開發者更容易閱讀和理解。

到目前為止，我們主要討論了 XML 形式的全局配置，其實這也不是唯一選擇，MyBatis 還提供了通過代碼來進行配置的方式：

清單??10.??在??MyBatis??中使用代碼進行配置

?DataSource ds = …… // 獲取一個 DataSource ?TransactionFactory txFactory = new JdbcTransactionFactory(); ?Environment env = new Environment("demo", txFactory, ds); ?Configuration cfg = new Configuration(env); ?cfg.addMapper(UserInfoMapper.class); ?SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(cfg);

　　結合前面的配置文件，很容易理解這段代碼的意思，故不再贅述。不過，需要注意的是 Configuration 的 addMapper() 方法，該方法的參數通常是一個接口，可以在接口里面定義若干方法，在方法上使用注解來指定映射的 SQL 語句。一個典型的接口定義以及對應的數據訪問方法如下：

清單??11.??將映射的??SQL??語句與接口中的方法綁定

????// 映射 SQL 綁定接口 ?public interface UserInfoMapper ?{ ?@Select("select * from userinfo where userid = #{userid}") ?public UserInfo getUserInfo(int userid); ?} ?// 接口綁定對應的數據訪問方法 ?try ?{ ?//UserInfo userinfo = (UserInfo) sqlSession.selectOne ?("mybatis.demo.UserInfoMapper.selectUser", 2); ?UserInfoMapper userinfoMapper = ?sqlSession.getMapper(UserInfoMapper.class); ?UserInfo userinfo = userinfoMapper.getUserInfo(1); ?System.out.println(userinfo); ?} finally ?{ ?sqlSession.close(); ?}

MyBatis??映射文件的改變

　　MyBatis 針對映射文件進行格式調整的地方很多，但大部分僅僅只是名稱上的變化，現代的 IDE 都支持聯想功能，可以很方便的獲取到當前位置可以有哪些元素、哪些屬性等。所以這基本不會給開發者造成什么麻煩。

針對映射文件，首先是一系列的屬性名稱的改變，這些僅僅是名稱的改變，用法和含義并沒有發生變化：

• 和全局配置文件一樣，由于 DTD 約束發生變化，根元素也由原來的 <sqlMap> 調整為 <mapper>。
• <select> 等元素的 parameterClass 屬性改為了 parameterType 屬性。
• <select> 等元素的 resultClasss 屬性改為了 resultType 屬性。
• <parameterMap> 等元素的 class 屬性改為了 type 屬性。
• <result> 元素的 columnIndex 屬性被移除了。
• 嵌套參數由 #value# 改為了 #{value}。
• <parameter> 等元素的 jdbcType 屬性取值中，原來的 "ORACLECURSOR" 取值改為了現在的 "CURSOR"，"NUMBER" 取值改為了 "NUMERIC"。

iBatis/MyBatis 對存儲過程的支持一直是值得稱道的。之前通過使用 <procedure> 元素進行存儲過程的定義，示例如下：

清單??12. iBatis??中調用存儲過程的方式

<procedure id="getValues" parameterMap="getValuesPM"> ????{ ? = call pkgExample.getValues(p_id => ?) } ?</procedure>

　　在 MyBatis 中，<proccedure> 元素已經被移除，通過 <select>、<insert> 和 <update> 進行定義：

清單??13. MyBatis??中調用存儲過程的方式

　　如上所示，通過 statementType 屬性將該語句標識為存儲過程而非普通 SQL 語句。

代碼層面的改變

　　通過前面的示例可以看出，MyBatis 在編碼中的最大的改變就是將一個最常用的 API 由 SqlMapClient 改為了 SqlSessionFactory。另外，類型處理器接口也由原來的 TypeHandlerCallback 改為了 TypeHandler。最后 DataSourceFactory 也進行了調整，移動到 org.apache.ibatis.datasource 包下，其中的方法也作了微調。總之，代碼層面公開的部分改動較少，不會給開發者造成較大的移植成本。

轉載于:https://www.cnblogs.com/boyangx/p/4133673.html

總結

以上是生活随笔為你收集整理的搞定MyBatis的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。