Overall Performance

The performance of iBATIS is very good. Because iBATIS allows you to write your own SQL statements in the sqlMap files, you are free to use additional features of the database server you are using. You also have full control over the data that is selected into the columns. For instance, there is no reason why you cannot perform the code in Listing 10-42.

Listing 10-42: sqlMap File for the Test Domain Object

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN" ¿ "http://www.ibatis.com/dtd/sql-map-2.dtd">   <sqlMap>          <typeAlias type="com.apress.prospring.ch12.domain.Test" alias="test"/>          <resultMap  bold">result">         <result property="testId" column="TestId"/>         <result property="name" column="Name"/>         <result property="runDate" column="RunDate"/>     </resultMap>              <select  resultMap="result">         select (1+1) as TestId, 'foo'     </select> </sqlMap> 

Even though this is not a typical select statement, it demonstrates your full control over the selected data and the way the data is selected.

You need to consider possible performance implications of N+1 selects when selecting object properties of domain objects. In most cases, however, you can absorb the performance hit by splitting the resultMaps into a basic one that is used for selects that return large number of rows and one that extends the basic resultMap to set more complex properties when you know that the number of rows is not going to be very large. As always, do not guess, measure the performance!

As we have already stated in the chapter introduction, the most important advantage of iBATIS is that it does not generate any code. Therefore, you have no data selection language to learn and you do not have to translate to the database's SQL code. This allows you to use nonstandard extensions to the SQL language provided by your database.

Bean configuration in separate XML files also help you to keep the code relatively easy to manage.

The actual data operations are incredibly simple; the built-in types allow you to pass almost any parameters to the database operations without having to create specific Java beans for them.

We have highlighted several limitations in the code. The one that bothers us the most is that there is no support for persistent enumerations and object canonicalization. This is an unfortunate side effect of almost every ORM framework we have worked with so far. You have to sacrifice a bit of the ideal design to accommodate the features or the lack of features of the framework you are using. However, iBATIS is the least obtrusive framework we have seen so far. However, we do encourage you to read about Hibernate—it is a truly data-RAD tool and the SQL code it generates is actually very good.