http://cse-mjmcl.cse.bris.ac.uk/blog/2005/12/12/1134408595646.html

I have looked at using Spring and the JDBCTemplate looks like a nice way to handle JDBC access without the need to write all that tedious connection code and exception handling stuff. However, unless I go to great effort I'd probably end up with SQL hard coded in my Java classes and I'd need to do all the resultset to object mapping by hand.

I discovered iBATIS recently almost by accident. iBATIS used to be a commercial product but has now been donated to the Apache Foundation. iBATIS is an O/RM-like approach. Clinton Begin, iBATIS creator, says that "iBATIS is not an O/RM. It does not bind classes to tables, nor does is it limited to OO languages and/or relational databases" and elsewhere iBATIS has been described as a convenience framework for JDBC. iBATIS does not offer some of the benefits that Hibernate does (database independence etc) but on the plus side it is very simple to use and even more so if you choose to use Spring's SqlMapClientTemplate.

I came across iBATIS as it was one of the technologies included as an example Jetspeed2 Portlet. iBATIS distribute JPetstore as an example of using Struts, DAO layer and iBATIS together. The Jetspeed2 version of the application uses the Struts bridge to convert the application into a portlet. The idea behind iBATIS is that all your SQL is kept in an external XML SQLMapping file. iBATIS then maps the returned result into a domain object.

Spring includes support for iBATIS interaction. I spent a little time studying the iBATIS JPetstore example and a version of this which actually uses Spring is further explored in Bruce Tate and Justin Gehtland's book Better, Faster, Lighter Java (excerpts of which can be found on the OnJava web site [Demonstrating Spring's Finesse, Persistence in Spring]).

There is a Perl script which can be used to generate java-beans sources and sql-map config files generator. There is now also some iBATIS support inside Middlegen tool for the generation of iBATIS SQLMapping XML files and associated domain object POJOs. Looking at the DAO approach used in Better, Faster, Lighter Java and similarly using Spring's iBATIS support it seemed very possible to me that I could extend the existing iBATIS Middlegen Plugin so that it would generate the required DAO classes to implement the architecture shown in the diagram below.

The default iBATIS Middlegen plugin generates the CRUD actions needed for the SQL mapping and creates the definition of each domain object. It was relatively straight forward to modify these basic examples to create DAO interfaces, DAO implementation (using Spring SQLMapClientTemplates) and also a Façade interface / implementation.

To do this I had to learn a to use the Velocity Templating Language (VTL) to extend Middlegen code but since I have some shell scripting and XSL experience this is not that daunting a task.

Using the default Middlegen iBATIS plugin you can create an SQL Mapping file and domain object POJO class. For this example I have created a single Table called ITEM with one column containing an ITEM_ID. The generated iBATIS XML SQLMapping file is shown below. Notice how this contains the full range of CRUD operations.

<?xml version='1.0'?>
<!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
    "http://www.ibatis.com/dtd/sql-map-2.dtd">

<!-- WARNING: This is an autogenerated file -->

<sqlMap>        
        <typeAlias alias="Item" type="mypackage.domain.Item"/>
        <!--
    <cacheModel id="$table.destinationClassName-cache" type="MEMORY">
        <flushInterval hours="24"/>
        <flushOnExecute statement="insertItem"/>
        <flushOnExecute statement="updateItem"/>
        <flushOnExecute statement="deleteItem"/>
        <property name="reference-type" value="WEAK" />
    </cacheModel>
        -->
    <resultMap class="Item" id="Item-result" >
        <result
                property="itemId"
                javaType="java.lang.String"
                column="ITEM_ID"
        />
    </resultMap>

    <select id="getItem"
        resultClass="Item"
        parameterClass="Item"
        resultMap="Item-result" >
        <![CDATA[
            select
                ITEM_ID
            from
                ITEM
            where
                ITEM_ID = #itemId#

        ]]>
    </select>

    <update id="updateItem"
        parameterClass="Item" >
        <![CDATA[
            update
                        ITEM
            set

            where
                ITEM_ID = #itemId#
        ]]>
    </update>

    <insert id="insertItem"
        parameterClass="Item" >
        <![CDATA[
            insert into ITEM
              (ITEM_ID )
            values
              (#itemId# )
        ]]>
    </insert>

    <delete id="deleteItem" parameterClass="Item"  >
        <![CDATA[
            delete from ITEM where ITEM_ID = #itemId#
        ]]>
    </delete>

</sqlMap>

The default Middlegen iBATIS plugin will generate corresponding transparent domain object class (business objects), one per table. The domain should capture the relationships between the various system entities much as an Entity Relationship Diagram does and this is why we can generate this from the database directly. The generated classes are a "bare" platform into which you should expect to add more sophisticated behaviours. These really should contain behaviour as you'll probably recall from object oriented programming first principles a class should contain data and methods. Obviously the precise behaviour cannot be generically generated as it is likely to be domain object specific. If you do not add additional behaviour at this point you may be guilty of using an Anemic Domain Model.

package mypackage.domain;

import java.io.Serializable;
import java.sql.Timestamp;
import java.math.BigDecimal;
import org.apache.commons.lang.builder.HashCodeBuilder;

/**
 * @author <a href="http://boss.bekk.no/boss/middlegen/">Middlegen</a>
 *
 */
public class Item implements Serializable 
{
    // fields
    /**
     * The itemId field
     */
    private java.lang.String itemId;

    // getters/setters
    /**
     * Returns the itemId
     *
     * @return the itemId
     */
    public java.lang.String getItemId() 
    {
        return itemId;
    }

    /**
     * Sets the itemId
     *
     * @param newItemId the new itemId
     */
    public void setItemId(java.lang.String newItemId) {
        this.itemId = newItemId;
    }


    /**
     *  Implementation of equals method.
     */
    public boolean equals(Object object) 
    {
        if (this == object)
        {
            return true;
        }
        if (!(object instanceof Item))
        {
            return false;
        }
        Item other = (Item)object;
        return
                  this.itemId.equals(other.itemId);      }

     /**
      * Implementation of hashCode method that supports the
      * equals-hashCode contract.
      */
/*
    public int hashCode()
    {
        return
             hashCode(this.itemId);     }
*/
     /**
      * Implementation of hashCode method that supports the
      * equals-hashCode contract.
      */
    public int hashCode() 
    {
        // TODO generate random number following the contract
        HashCodeBuilder builder = new HashCodeBuilder(17,37);
        return builder
            .append(itemId)
            .toHashCode();
    }

    /**
     *  Implementation of toString that outputs this object id's
     *  primary key values.
     */
    public String toString() 
    {
        StringBuffer buffer = new StringBuffer();
        buffer.append("itemId=");
        buffer.append(this.itemId);
            return buffer.toString();
        /*
        return
             this.itemId;           */
    }
}

I created Middlegen iBATIS Plugin extensions to generate the next few classes. This is an example of a generated DAO interface class. There will be one DAO interface class per domain object (i.e. one per table).

package mypackage.iface;

import  mypackage.domain.Item;

public interface ItemDao
{
    public Item getItem( java.lang.String itemId);
    public void insertItem(Item item);
    public void updateItem(Item item);
    public void deleteItem(Item item);

}

This is DAO implementation of the above interface using Spring's SqlMappingClientTemplate, again there will be one of these per domain object (i.e. one per table):

package mypackage.sqlmapdao;

import mypackage.domain.Item;
import mypackage.iface.ItemDao;
import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;

public class SqlMapItemDao extends SqlMapClientDaoSupport implements ItemDao
{
    public Item getItem(java.lang.String itemId){
        Item item = new Item();
        item.setItemId(itemId);
    return (Item) getSqlMapClientTemplate().queryForObject("getItem",item);
    }

    public void insertItem(Item item) {
        getSqlMapClientTemplate().insert("insertItem",item);
    }

    public void updateItem(Item item){
        getSqlMapClientTemplate().update("updateItem",item);
    }

    public void deleteItem(Item item){
        getSqlMapClientTemplate().delete("deleteItem",item);
    }

}

In this most simple example the usage of a façade seems fairly pointless. The idea comes into it's own when you start to have more than one table of data represented in your domain. A façade collects all the publicly accessible DAO methods into a single interface. It also serves as an attachment point for other services, such as transaction support. In writing a Struts Action you would query against the façade rather than trying to obtain a DAO method directly. There will be only one instance of the façade layer interface and implementation it will likely contain references to all the DAO interfaces for every publicly accessible domain object.

See Persistence in Spring for more details about why we might want to generate a façade interface and implementation.

Façade interface:

package mypackage.domain.logic;

import mypackage.domain.Item;

public interface Façade
{

    public Item getItem( java.lang.String itemId);
    public void insertItem(Item item);
    public void updateItem(Item item);
    public void deleteItem(Item item);

}

Façade implementation:

package mypackage.domain.logic;

import mypackage.iface.ItemDao;
import mypackage.domain.Item;

public class FaçadeImpl implements Façade
{

    private ItemDao itemDao;

//-------------------------------------------------------------------------
// Setter methods for dependency injection
//-------------------------------------------------------------------------


    public void setItemDao(ItemDao itemDao) {
        this.itemDao = itemDao;
    }

//-------------------------------------------------------------------------
// Operation methods, implementing the Façade interface
//-------------------------------------------------------------------------



    public Item getItem( java.lang.String itemId){
    	return this.itemDao.getItem(itemId);
    }

    public void insertItem(Item item){
        this.itemDao.insertItem(item);
    }

    public void updateItem(Item item){
        this.itemDao.updateItem(item);
    }

    public void deleteItem(Item item){
        this.itemDao.deleteItem(item);
    }

}

As you can see from the above examples, I have now extended the Middlegen iBATIS Plugin to create a simple version of the entire Spring based DAO layer code. I'm currently looking into generating more complex domain relationship behaviour but this has so far only been slightly hampered by my limited VTL scripting skills but it is certainly possible to do this with Middlegen as the Hibernate and EJB plugins produce something similar. I am hoping to better capture one-to-many relationships in the domain model so that I can detect these and generate appropriate SQLMapping and Java code. For example if we added a new domain object called CATEGORY it might contain many ITEMS and could therefore our Category domain object might contain:

private List items;

public List getItems()
{
    return items;
}

public void setItems(List items)
{
    this.items = items;
}

The following could be generated inside an appropriate XML SQL Mapping file:

<select
    id="getItemsByCategoryCode"
    parameterClass="java.lang.String"
    resultMap="itemMap">        
    select
        item_id,
        item_name,
        category_code
    from
        items
    where
        category_code = #value#;
</select>

* where itemMap is already defined someplace.

The Spring DAO implementation of this could then look something like:

public List findItems(Category category){
    getSqlMapClientTemplate().queryForList("getItemsByCategoryCode",category);
}

public void createCategoryWithItems(Category category){
    getSqlMapClientTemplate().execute(new SqlMapClientCallback() {
         public Object doInSqlMapClient(SqlMapExecutor executor) throws SQLException {
                 executor.startBatch();
        for (Iterator it=category.getItems().iterator(); it.hasNext(); ) {
                Item item = (Item) it.next();
                executor.insert("insertItem", item);
            }
                 executor.executeBatch();
                 return null;
         }
 });
}

Nothing that I have generated so far is especially complicated but it is still nice to be able to generate basic business objects and a working DAO layer without much effort. I'd be happy to share the Velocity templates that I used to create these classes.