Mybatis-入門篇


Mybatis-入門篇

安裝

要使用 MyBatis, 只需將 mybatis-x.x.x.jar 文件置於 classpath 中即可。

如果使用 Maven 來構建項目,則需將下面的 dependency 代碼置於 pom.xml 文件中:

<code><dependency>  <groupid>org.mybatis/<groupid>  <artifactid>mybatis/<artifactid>  <version>x.x.x/<version>/<dependency>/<code>

從 XML 中構建 SqlSessionFactory

每個基於 MyBatis 的應用都是以一個 SqlSessionFactory 的實例為核心的。SqlSessionFactory 的實例可以通過 SqlSessionFactoryBuilder 獲得。而 SqlSessionFactoryBuilder 則可以從 XML 配置文件或一個預先定製的 Configuration 的實例構建出 SqlSessionFactory 的實例。

從 XML 文件中構建 SqlSessionFactory 的實例非常簡單,建議使用類路徑下的資源文件進行配置。 但是也可以使用任意的輸入流(InputStream)實例,包括字符串形式的文件路徑或者 file:// 的 URL 形式的文件路徑來配置。MyBatis 包含一個名叫 Resources 的工具類,它包含一些實用方法,可使用 classpath 或其他位置加載資源文件更加容易。

<code>String resource = "org/mybatis/example/mybatis-config.xml";InputStream inputStream = Resources.getResourceAsStream(resource);SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);/<code>

XML 配置文件中包含了對 MyBatis 系統的核心設置,包含獲取數據庫連接實例的數據源(DataSource)和決定事務作用域和控制方式的事務管理器(TransactionManager)。 XML 配置文件的詳細內容後面再探討,這裡先給出一個簡單的示例:

<code><configuration>  <environments>    <environment>      <transactionmanager>      <datasource>        <property>        <property>        <property>        <property>      /<datasource>    /<environment>  /<environments>  <mappers>    <mapper>  /<mappers>/<configuration>/<code>

當然,還有很多可以在 XML 文件中進行配置,上面的示例指出的則是最關鍵的部分。 要注意 XML 頭部的聲明,它用來驗證 XML 文檔正確性。environment 元素體中包含了事務管理和連接池的配置。mappers 元素則是包含一組映射器(mapper),這些映射器的 XML 映射文件包含了 SQL 代碼和映射定義信息。

不使用 XML 構建 SqlSessionFactory

如果你更願意直接從 Java 代碼而不是 XML 文件中創建配置,或者想要創建你自己的配置構建器,MyBatis 也提供了完整的配置類,提供所有和 XML 文件相同功能的配置項。

<code>DataSource dataSource = BlogDataSourceFactory.getBlogDataSource();TransactionFactory transactionFactory = new JdbcTransactionFactory();Environment environment = new Environment("development", transactionFactory, dataSource);Configuration configuration = new Configuration(environment);configuration.addMapper(BlogMapper.class);SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(configuration);/<code>

注意該例中,configuration 添加了一個映射器類(mapper class)。映射器類是 Java 類,它們包含 SQL 映射語句的註解從而避免依賴 XML 文件。不過,由於 Java 註解的一些限制以及某些 MyBatis 映射的複雜性,要使用大多數高級映射(比如:嵌套聯合映射),仍然需要使用 XML 配置。有鑑於此,如果存在一個同名 XML 配置文件,MyBatis 會自動查找並加載它(在這個例子中,基於類路徑和 BlogMapper.class 的類名,會加載 BlogMapper.xml)。具體細節稍後討論。

從 SqlSessionFactory 中獲取 SqlSession

既然有了 SqlSessionFactory,顧名思義,我們就可以從中獲得 SqlSession 的實例了。SqlSession 完全包含了面向數據庫執行 SQL 命令所需的所有方法。你可以通過 SqlSession 實例來直接執行已映射的 SQL 語句。例如:

<code>try (SqlSession session = sqlSessionFactory.openSession()) {  Blog blog = (Blog) session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);}/<code>

誠然,這種方式能夠正常工作,並且對於使用舊版本 MyBatis 的用戶來說也比較熟悉。不過現在有了一種更簡潔的方式 ——使用正確描述每個語句的參數和返回值的接口(比如 BlogMapper.class),你現在不僅可以執行更清晰和類型安全的代碼,而且還不用擔心易錯的字符串字面值以及強制類型轉換。

例如:

<code>try (SqlSession session = sqlSessionFactory.openSession()) {  BlogMapper mapper = session.getMapper(BlogMapper.class);  Blog blog = mapper.selectBlog(101);}/<code>

現在我們來探究一下這裡到底是怎麼執行的。

探究已映射的 SQL 語句

現在你可能很想知道 SqlSession 和 Mapper 到底執行了什麼操作,但 SQL 語句映射是個相當大的話題,可能會佔去文檔的大部分篇幅。 不過為了讓你能夠了解個大概,這裡會給出幾個例子。

在上面提到的例子中,一個語句既可以通過 XML 定義,也可以通過註解定義。我們先看看 XML 定義語句的方式,事實上 MyBatis 提供的全部特性都可以利用基於 XML 的映射語言來實現,這使得 MyBatis 在過去的數年間得以流行。如果你以前用過 MyBatis,你應該對這個概念比較熟悉。 不過自那以後,XML 的配置也改進了許多,我們稍後還會再提到。這裡給出一個基於 XML 映射語句的示例,它應該可以滿足上述示例中 SqlSession 的調用。

<code><mapper>  <select>    select * from Blog where id = #{id}  /<select>/<mapper>/<code>

為了這個簡單的例子,我們似乎寫了不少配置,但實際上它並不多。在一個 XML 映射文件中,可以定義無數個映射語句,這樣一來,XML 頭部和文檔類型聲明佔去的部分就顯得微不足道了。而文件的剩餘部分具備自解釋性,很容易理解。 在命名空間 “org.mybatis.example.BlogMapper” 中定義了一個名為 “selectBlog” 的映射語句,允許你使用指定的完全限定名 “org.mybatis.example.BlogMapper.selectBlog” 來調用映射語句,就像上面例子中那樣:

<code>Blog blog = (Blog) session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);/<code>

你可能注意到這和使用完全限定名調用 Java 對象的方法類似。這樣,該命名就可以直接映射到在命名空間中同名的 Mapper 類,並將已映射的 select 語句中的名字、參數和返回類型匹配成方法。 因此你就可以像上面那樣很容易地調用這個對應 Mapper 接口的方法,就像下面這樣:

<code>BlogMapper mapper = session.getMapper(BlogMapper.class);Blog blog = mapper.selectBlog(101);/<code>

第二種方法有很多優勢,首先它不依賴於字符串字面值,會更安全一點; 其次,如果你的 IDE 有代碼補全功能,那麼代碼補全可以幫你快速選擇已映射的 SQL 語句。


提示對命名空間的一點說明

在之前版本的 MyBatis 中,命名空間(Namespaces)的作用並不大,是可選的。 但現在,隨著命名空間越發重要,你必須指定命名空間。

命名空間的作用有兩個,一個是利用更長的完全限定名來將不同的語句隔離開來,同時也實現了你上面見到的接口綁定。就算你覺得暫時用不到接口綁定,你也應該遵循這裡的規定,以防哪天你改變了主意。 長遠來看,只要將命名空間置於合適的 Java 包命名空間之中,你的代碼會變得更加整潔,也有利於你更方便地使用 MyBatis。

命名解析:為了減少輸入量,MyBatis 對所有的命名配置元素(包括語句,結果映射,緩存等)使用瞭如下的命名解析規則。

  • 完全限定名(比如 “com.mypackage.MyMapper.selectAllThings)將被直接用於查找及使用。
  • 短名稱(比如 “selectAllThings”)如果全局唯一也可以作為一個單獨的引用。 如果不唯一,有兩個或兩個以上的相同名稱(比如 “com.foo.selectAllThings” 和 “com.bar.selectAllThings”),那麼使用時就會產生“短名稱不唯一”的錯誤,這種情況下就必須使用完全限定名。

對於像 BlogMapper 這樣的映射器類來說,還有另一種方法來處理映射。 它們映射的語句可以不用 XML 來配置,而可以使用 Java 註解來配置。比如,上面的 XML 示例可被替換如下:

<code>package org.mybatis.example;public interface BlogMapper {  @Select("SELECT * FROM blog WHERE id = #{id}")  Blog selectBlog(int id);}/<code>

使用註解來映射簡單語句會使代碼顯得更加簡潔,然而對於稍微複雜一點的語句,Java 註解就力不從心了,並且會顯得更加混亂。 因此,如果你需要完成很複雜的事情,那麼最好使用 XML 來映射語句。

選擇何種方式來配置映射,以及認為映射語句定義的一致性是否重要,這些完全取決於你和你的團隊。 換句話說,永遠不要拘泥於一種方式,你可以很輕鬆的在基於註解和 XML 的語句映射方式間自由移植和切換。

作用域(Scope)和生命週期

理解我們目前已經討論過的不同作用域和生命週期類是至關重要的,因為錯誤的使用會導致非常嚴重的併發問題。


提示 對象生命週期和依賴注入框架

依賴注入框架可以創建線程安全的、基於事務的 SqlSession 和映射器,並將它們直接注入到你的 bean 中,因此可以直接忽略它們的生命週期。 如果對如何通過依賴注入框架來使用 MyBatis 感興趣,可以研究一下 MyBatis-Spring 或 MyBatis-Guice 兩個子項目。


SqlSessionFactoryBuilder

這個類可以被實例化、使用和丟棄,一旦創建了 SqlSessionFactory,就不再需要它了。 因此 SqlSessionFactoryBuilder 實例的最佳作用域是方法作用域(也就是局部方法變量)。 你可以重用 SqlSessionFactoryBuilder 來創建多個 SqlSessionFactory 實例,但是最好還是不要讓其一直存在,以保證所有的 XML 解析資源可以被釋放給更重要的事情。

SqlSessionFactory

SqlSessionFactory 一旦被創建就應該在應用的運行期間一直存在,沒有任何理由丟棄它或重新創建另一個實例。 使用 SqlSessionFactory 的最佳實踐是在應用運行期間不要重複創建多次,多次重建 SqlSessionFactory 被視為一種代碼“壞味道(bad smell)”。因此 SqlSessionFactory 的最佳作用域是應用作用域。 有很多方法可以做到,最簡單的就是使用單例模式或者靜態單例模式。

SqlSession

每個線程都應該有它自己的 SqlSession 實例。SqlSession 的實例不是線程安全的,因此是不能被共享的,所以它的最佳的作用域是請求或方法作用域。 絕對不能將 SqlSession 實例的引用放在一個類的靜態域,甚至一個類的實例變量也不行。 也絕不能將 SqlSession 實例的引用放在任何類型的託管作用域中,比如 Servlet 框架中的 HttpSession。 如果你現在正在使用一種 Web 框架,要考慮 SqlSession 放在一個和 HTTP 請求對象相似的作用域中。 換句話說,每次收到的 HTTP 請求,就可以打開一個 SqlSession,返回一個響應,就關閉它。 這個關閉操作是很重要的,你應該把這個關閉操作放到 finally 塊中以確保每次都能執行關閉。 下面的示例就是一個確保 SqlSession 關閉的標準模式:

<code>try (SqlSession session = sqlSessionFactory.openSession()) {  // 你的應用邏輯代碼}/<code>

在你的所有的代碼中一致地使用這種模式來保證所有數據庫資源都能被正確地關閉。

映射器實例

映射器是一些由你創建的、綁定你映射的語句的接口。映射器接口的實例是從 SqlSession 中獲得的。因此從技術層面講,任何映射器實例的最大作用域是和請求它們的 SqlSession 相同的。儘管如此,映射器實例的最佳作用域是方法作用域。 也就是說,映射器實例應該在調用它們的方法中被請求,用過之後即可丟棄。 並不需要顯式地關閉映射器實例,儘管在整個請求作用域保持映射器實例也不會有什麼問題,但是你很快會發現,像 SqlSession 一樣,在這個作用域上管理太多的資源的話會難於控制。 為了避免這種複雜性,最好把映射器放在方法作用域內。下面的示例就展示了這個實踐:

<code>try (SqlSession session = sqlSessionFactory.openSession()) {  BlogMapper mapper = session.getMapper(BlogMapper.class);  // 你的應用邏輯代碼}/<code>


分享到:


相關文章: