事務、會話和工廠類——MapperFactory
我們應該在何處獲取“Mapper”的實例呢？我們仍然需要一個核心類來完成iBATIS的配置和控制。這個核心類的名稱尚在爭論之中，但是我們不妨先叫它MapperFactory。
通常情況下，MapperFactory負責構建事務和映射類的實例。而MapperFactory本身將由某個配置類來構建。
MapperFactory factory = someConfiguration.buildMapperFactory();
EmployeeMapper employeeMapper = factory.getMapper (EmployeeMapper.class);
對于這種方式是不是會使事情變得簡單...或許會吧！至于事務，Clinton是這樣說的：“會話的概念應該和事務的進行合并。在iBATIS中，會話和事務很多時候是一致甚至是一樣的。但是它們因為一些人為的架構方面的原因而被分開了。會話或許能夠完成不少任務，但是其中的80%并不適合用會話來解決。同樣的，批處理操作也從事務中分離出來，因為事務在提供批處理功能是往往會導致令人生厭的try/finally的多重嵌套。因此在我們發現真實的需求之前應該盡量避免這些。”。
iBATIS或者其他第三方庫及容器都可以進行事務處理。目前，事務的處理是由SqlMapClient實例中的ThreadLocal實例來處理的。因為這種處理方法，我們配到了不少問題。不是出于技術的原因而是因為代碼更加清晰，我們可以使用以下的方法：
Transaction tx = factory.startTransaction();
try
{
// do work
tx.commit();
}
finally
{
tx.end();
}
批處理操作可以簡單地通過啟動支持批處理操作的事務來進行：
Transaction tx = factory.startBatch();
try
{
// do work
// balk executes current batch immediately, returns total rows updated
// (balks on non-batched transactions)
int totalRowCount = tx.flush();
// commit executes batch too, returns total rows updated and commits
totalRowCount = tx.commit();
}
finally
{
tx.end();
}
與現在的事務的API類似，我們對事務的隔離級別以及其他選項提供支持。
Transaction tx = factory.startTransaction(isolationLevel);
try
{
// do work
tx.commit();
}
finally
{
tx.end();
}
如果第三方的庫提供了事務處理的支持，那么受托管理的連接對象可以作為參數傳入：
// Can be handled by encapsulating framework (e.g. Spring)
Transaction tx = factory.useConnection(conn);
try
{
//...do work...
tx.flush(); // executes batched updates immediately
// commit simply calls commit on the connection
// if local commits are allowed, otherwise it is ignored.
tx.commit();
}
finally
{
tx.end(); // Can also be handled by encapsulating framework (e.g. Spring)
}
總之，這樣的API十分的簡潔，而且易于與諸如Spring這樣的第三方框架集成。MapperFactory可以被注入到需要事務管理、批處理和隔離級別的Spring的DAO對象中。為了進一步進行必要的分離，我們可以將事務管理功能從MapperFactory中分離出來，甚至于允許開發者定義自己的事務管理接口，同時將事務管理的功能綁定到類中（這樣提供了更加松耦合的架構）。