![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
What is iBATIS?
This section describes the separate APIs within iBATIS and why you might use them, and identifies iBATIS's advantages over other database-mapping frameworks.
Simply put, iBATIS consists of two separate frameworks. You use the Data Mapper framework specifically for OR mapping, which is the mapping of your Java domain objects to relational tables in a database. The DAO framework gives your application a clean and consistent way to access underlying data.
iBATIS Data Mapper framework (Data Mapper)
The Data Mapper is the framework that executes your SQL and maps the results back to objects, saving you from having to do this manually.
The Data Mapper framework doesn't require you to make any special version of your Java objects. You don't need to implement any interfaces or generate any code. You don't need to subclass some other base object or perform any strange rituals. And you don't need to learn a secondary query language specific to the framework.
You use a simple and straightforward XML format to define the manner in which iBATIS maps your Java objects to the database. You can define the exact query you need directly in SQL and optionally use any proprietary SQL that is specific to the database engine you're using. This capability lets you map your objects exactly the way you want and perform joins exactly the way you want.
iBATIS Data Access Objects framework (DAO framework)
The DAO framework's main goal is to abstract the how and where of your application's data-access or persistence layer from the application's business logic. The DAO framework lets you define interfaces in your application that are responsible for data-centric operations.
For example, if your application uses straight-up Java Database Connectivity (JDBC) for persistence, the DAO framework's goal is to abstract the use of classes and interfaces, such as Connection, PreparedStatement, and ResultSet, away from your application and move it down into a persistence layer instead.
If your application for some reason uses HTTP GETs and POSTs to get and store data, then the DAO framework's purpose becomes to abstract the use of classes, such as HttpUrlConnection, away from your application's business layer. Your application can then use the DAO interfaces to perform operations on your data, and the implementations of these interfaces are abstracted away from your business logic. The implementations can retrieve data from a database, a Web service, or any other source.
The DAO framework doesn't depend on the use of the Data Mapper framework. You can use both frameworks in a project should you choose (and they pair quite nicely), or you can use each one independently. This tutorial series shows the advantages of using the frameworks alone and together.
iBATIS has some advantages over other OR mapping tools:
- iBATIS doesn't use its own proprietary query language; it just uses SQL. Some OR mapping tools, such as Hibernate, use their own query languages in addition to SQL.
- All the queries and updates you want to perform are written in SQL (and stored in .xml files). Some people might consider this a disadvantage, wanting the database abstracted from them completely to avoid needing to write any SQL code. This is one reason a lot of developers like Hibernate. But you might prefer to have fine-grained control over exactly what SQL is being executed when you access your objects, rather than having it unpredictably generated for you in a manner dependent on the underlying OR mapping framework. You can fine-tune your queries and other statements based on recommendations by a database administrator (DBA) or by access plans or query optimizers provided by the tools supplied with your relational database management system (RDBMS). Another benefit of having direct access over the SQL that is written for this layer is that you can take advantage of any proprietary SQL offered by your database.
- It's easy to use.
- The project is well documented.
- It has no external dependencies. Some of the other OR mapping frameworks ship with 15 to 20 .jar files and are dependent on specific versions of these files just to let the framework run. You don't need or want that kind of a headache when developing applications, so the fact that you can use iBATIS without any external dependencies is a huge plus. (Note that some optional configurations let you enable things like an external connection pool or bytecode enhancement, but none of them is required.)
Now it's time to dive into some more specific iBATIS concepts and semantics, which eventually lead to some coding and examples.
