MyiBatis總結

1. 介紹

iBatis是一個資料映射架構，它使我們的Java/.Net應用程式能夠更加簡潔的跟資料庫打交道。iBatis通過一系列的XML配置檔案，解耦了對象和存儲過程/SQL語句。與其他ORM工具相比，iBatis的最大優點就是簡潔，包括其官方文檔，也就92頁。根據iBatis的宣稱，其目的是使用20%的代碼完成資料通路80%的功能。

iBatis的.Net版本的官方網址是：http://www.mybatis.org/dotnet.html，

源代碼的svn路徑是：http://mybatisnet.googlecode.com/svn/trunk

2. iBatis做了什麼

iBatis所做的功能其實很簡單，概括起來就是：我們提供資料庫和對象，iBatis為我們提供映射關系。

3. iBatis如何工作

關于跟資料庫打交道，我們知道每個開發平台都為我們提供了相應的方式，如Ado.Net，但是，對于開發人員來說，我們依舊發現一些比較難的問題：

• 将程式代碼和SQL代碼分隔開；
• 傳遞參數到程式類和解壓輸出結果；
• 将資料通路類從業務邏輯類從分割開；
• 緩存經常用到的資料直到資料源發生變化；
• 管理實務和線程

幸運的是，iBatis為我們解決了上述問題。

我們首先來看一張iBatis的工作流程圖：

​​

​​

圖檔來源：官方的文檔《Data Mapper Guid-1.6.2》

從這個流程圖中，我們可以看出，iBatis的工作流大概是這樣的：

1. 提供一個輸入參數，可以是自定義的類或者是原始的資料類型。這個參數可以在SQL語句或存儲過程中動态的設定值。當然，如果我們沒有必要在運作時值，輸入參數是可以省略的；
2. 在XML配置檔案中，通過傳遞的參數和SQL語句或存儲過程中的名字，進行映射。這一步是真正發生奇迹的步驟，iBatis将準備SQL語句/存儲過程，用我們提供的參數設定運作時值，執行SQL語句/存儲過程，然後傳回結果；
3. 對于更新(update/insert/delete)的情況，傳回受影響的行數，對于查詢的情況，一個對象，或者對象的集合将被傳回，跟輸入參數一樣，傳回值也可以是自定義的類，或者原始的類型。

4. iBatis是你項目的最佳選擇嗎？

對于項目中使用的任何技術，我們都會有個問題，這種技術适合我們的項目嗎？它是不是最佳的選擇呢？有沒有更好的選擇呢？對于iBatis，我們同樣會有這樣的問題，為了搞清這個問題，我們需要将iBatis跟具有同類功能的産品進行對比。

首先，iBatis是一個資料映射工具，他的功能是将資料庫中查詢出來的列映射到對象的屬性(Property)中，如果你的項目是基于業務對象(business objects)的，那麼iBatis應該是一個不錯的選擇；如果你的項目是基于多層架構的，那麼iBatis甚至是一個更好的選擇，因為這樣業務層和UI層将很輕易的分割開。

基于上面的情況，另外一個好的選擇方案是OR/M(Object/Relational Mapping Tool)工具，像NHibernate。OR/M為我們生成了大部分的SQL，這類工具之是以叫OR/M，是因為他們試圖将一個對象圖映射到關系模式中。

iBatis并不是一個OR/M工具，它所做的隻是幫我們将對象映射到SQL語句/存儲過程。如果我們的對象和表示對應的，那麼OR/M将是一個不錯的選擇，但是，如果我們的對象存儲的是關系視圖，而不是簡單的資料庫表，那麼OR/M就不一定是一個好的選擇方案了。

總之，iBatsi是一個很好的選擇方案，如果你：

1. 不能夠完全掌控資料庫的實作，或者你想要通路一個被重構過的資料庫的原始資料庫；
2. 組裡面有資料庫管理者或SQL專家
3. 資料庫是用來模型化問題域的，并且應用程式是首要職責是幫助用戶端使用資料庫模型

1. 介紹

iBatis是一個資料映射架構，它使我們的Java/.Net應用程式能夠更加簡潔的跟資料庫打交道。iBatis通過一系列的XML配置檔案，解耦了對象和存儲過程/SQL語句。與其他ORM工具相比，iBatis的最大優點就是簡潔，包括其官方文檔，也就92頁。根據iBatis的宣稱，其目的是使用20%的代碼完成資料通路80%的功能。

iBatis的.Net版本的官方網址是：http://www.mybatis.org/dotnet.html，

源代碼的svn路徑是：http://mybatisnet.googlecode.com/svn/trunk

2. iBatis做了什麼

iBatis所做的功能其實很簡單，概括起來就是：我們提供資料庫和對象，iBatis為我們提供映射關系。

3. iBatis如何工作

關于跟資料庫打交道，我們知道每個開發平台都為我們提供了相應的方式，如Ado.Net，但是，對于開發人員來說，我們依舊發現一些比較難的問題：

• 将程式代碼和SQL代碼分隔開；
• 傳遞參數到程式類和解壓輸出結果；
• 将資料通路類從業務邏輯類從分割開；
• 緩存經常用到的資料直到資料源發生變化；
• 管理實務和線程

幸運的是，iBatis為我們解決了上述問題。

我們首先來看一張iBatis的工作流程圖：

​​

​​

圖檔來源：官方的文檔《Data Mapper Guid-1.6.2》

從這個流程圖中，我們可以看出，iBatis的工作流大概是這樣的：

1. 提供一個輸入參數，可以是自定義的類或者是原始的資料類型。這個參數可以在SQL語句或存儲過程中動态的設定值。當然，如果我們沒有必要在運作時值，輸入參數是可以省略的；
2. 在XML配置檔案中，通過傳遞的參數和SQL語句或存儲過程中的名字，進行映射。這一步是真正發生奇迹的步驟，iBatis将準備SQL語句/存儲過程，用我們提供的參數設定運作時值，執行SQL語句/存儲過程，然後傳回結果；
3. 對于更新(update/insert/delete)的情況，傳回受影響的行數，對于查詢的情況，一個對象，或者對象的集合将被傳回，跟輸入參數一樣，傳回值也可以是自定義的類，或者原始的類型。

4. iBatis是你項目的最佳選擇嗎？

對于項目中使用的任何技術，我們都會有個問題，這種技術适合我們的項目嗎？它是不是最佳的選擇呢？有沒有更好的選擇呢？對于iBatis，我們同樣會有這樣的問題，為了搞清這個問題，我們需要将iBatis跟具有同類功能的産品進行對比。

首先，iBatis是一個資料映射工具，他的功能是将資料庫中查詢出來的列映射到對象的屬性(Property)中，如果你的項目是基于業務對象(business objects)的，那麼iBatis應該是一個不錯的選擇；如果你的項目是基于多層架構的，那麼iBatis甚至是一個更好的選擇，因為這樣業務層和UI層将很輕易的分割開。

1. 不能夠完全掌控資料庫的實作，或者你想要通路一個被重構過的資料庫的原始資料庫；
2. 組裡面有資料庫管理者或SQL專家
3. 資料庫是用來模型化問題域的，并且應用程式是首要職責是幫助用戶端使用資料庫模型