iBATIS Under the Hood
Like other persistence layers, iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database communication (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based upon an object's state, mapping of complex joins to complex object graphs, etc.). The iBATIS approach to this is very straightforward: use XML to loosely couple your Java objects and SQL commands.
The iBATIS Database Layer consists of the following two libraries:
- iBATIS Data Access ObjectsAlthough this is a well-designed library, this article uses Spring as the application backbone. As such, it uses Spring's DAO layer for abstracting the communication with the persistence layer. This allows the flexibility to easily switch to any supported persistence framework, including Hibernate, JDO, or Apache OJB.
- iBATIS Data MapperThis library is the core of what makes iBATIS special. It allows developers to flexibly map pure SQL to Java collections or custom domain objects. In doing so, development responsibilities are cleanly divided. DBAs can work with pure SQL devoid of language-specific constructs, and business developers can write pure OO business logic without regard for database semantics.
The remainder of the article uses the term iBATIS synonymously with the iBATIS Data Mapper library.
iBATIS loosely couples objects with SQL by using XML configuration. A top-level configuration file (
) lays out the core environment and then points to various SQL maps (
) that in turn define how to map between SQL calls and the Java layer. From there, it is simply a matter of working with collections or POJOs (plain old java objects) to read data from or make changes to the database layer. Figure 1
illustrates this approach.
The approach discussed here goes one step further by wiring everything together via Spring. In this case, the Spring configuration file (
applicationContext.xml) is used to define the core environment and the role of the iBATIS config file (
SqlMapConfig.xml) is diminished. Also, the Spring DAO layer is used in lieu of the iBATIS-specific application calls. Figure 2 illustrates the new architecture when Spring is incorporated.
|Figure 2. Spring Framework with iBATIS Persistence Layer|
As previously stated, the Spring Framework supports several alternative persistence layers (Hibernate, JDO, Apache OJB, etc.). The incumbent in this arena clearly is Hibernate. As you will learn later, iBATIS allows you to work with native SQL and hook your Java object layer to your database layer with a minimal level of configuration and mapping. So iBATIS generally is better suited than Hibernate for the following situations:
- You need to integrate with an existing database.
- Your DBAs and application developers tend to work separately.
- You have more junior Java developers.
- Your data model is relatively simple.
Hibernate is better suited to situations when you have a greater degree of control over the data model, when you are working with more senior Java developers, or when you have a relatively complex data model that you need to map to one or more object graphs. That's where it shines.