Integrating JDBC with Hibernate

One of the powerful things about Hibernate is that you do not typically need to manually write SQL: you build a domain model that represents your data model in an object-oriented manner and then interact with your domain model. This is the ideal, but sometimes
you need to model a legacy data model or a data model that is not object-oriented in nature, which leads to either complicated Hibernate mappings or the inclusion of manual SQL. When this occurs, you do not want to have to build separate data access object
classes but rather you would like to find a way to seamlessly integrate SQL into your existing data access object classes in a way that your consumers do not even realize that you're not using Hibernate Query Language (HQL) under-the-hood.

Fortunately you do not need to jump through too many hoops to integrate manual JDBC into your Hibernate classes, you just need to perform the following steps:

1. Obtain access to your Hibernate's Session object
2. Create a class that implements org.hibernate.jdbc.Work, or create an anonymous inner class that implements the Work interface, and implement the execute() method
   using the supplied Connection object to execute your SQL
3. Pass the Work class to Hibernate's doWork() method, which in turn invokes your Work's execute() method

Listings 1 and 2 illustrate how to use the Work interface to execute a simple SQL statement.

Listing 1. MyDao.java

...
public class MyDao
{
    ...
    public String getValue( long id )
    {
        // Create a SQL order of work, which we will use to execute a manual SQL statement
        MyWork myWork = new MyWork( id );

        // Gain access to the underlying Hibernate session
        Session session = getSessionFactory().openSession();

        // Ask the Hibernate session to execute the unit of work
        session.doWork( myWork );

        // Obtain the results of the unit of work
        return myWork.getValue();
    }
    ..
}

Listing 1 defines a getValue() method that accepts an id and returns a String. It creates a newMyWork instance, passing it the id as an initialization parameter, locates a Hibernate Session, and
passes the MyWork instance to the Sessions doWork() method. After the query is complete, it retrieves the value from the MyWork class.

The mechanism that you use to obtain a Hibernate Session will be dependent on the technology with which you are building your data access object. If you're using Spring by extendingHibernateDaoSupport, you can invoke getSessionFactory().openSession() to
create a new Session object.

Listing 2 shows the source code for the MyWork class.

Listing 2. MyWork.java

public class MyWork implements Work
{
    private long id;
    private String value;

    public MyWork( long id )
    {
        this.id = id;
    }

    public String getValue()
    {
        return value;
    }

    @Override
    public void execute( Connection connection ) throws SQLException
    {
        PreparedStatement ps = null;
        ResultSet rs = null;
        try
        {
            ps = connection.prepareStatement( "SELECT * FROM table WHERE id = ?" );
            ps.setLong( 1, id );
            rs = ps.executeQuery();
            while( rs.next() )
            {
                value = rs.getString( 1 );
            }
        }
        catch( SQLException e ) { }
        finally  {
            if( rs != null )
            {
                try {
                    rs.close();
                }
                catch( Exception e ) {}
            }
            if( ps != null )
            {
                try {
                    ps.close();
                }
                catch( Exception e ) {}
            }
        }
    }
}

The MyWork class implements its data access logic in its execute() method. The execute() method is passed a java.sql.Connection object that you can use as you normally
would to create aStatement, PreparedStatement, or CallableStatement. The doWork() method returns void, so it is up to you to develop
a mechanism to return a value from your unit of work.

If you are executing SQL from which you do not necessarily need to retrieve results, you can accomplish the same results by creating an anonymous inner class:

       // Gain access to the underlying Hibernate session
        Session session = getSessionFactory().openSession();

        // Ask the Hibernate session to execute the unit of work
        session.doWork( new Work() {
            @Override
            public void execute( Connection connection ) {
                // Implement your SQL here
            }
	} );

In this example we create the Work() implementation in the doWork() method invocation and override the execute() method. Depending on your background this might look a bit strange, but once you get used to it, this is a fairly elegant way to implement your
solution because it reduces the number of explicit classes you need to create and it couples the logic being executed with the invocation of that logic. For complicated cases you want to loosely couple things, but for a SQL statement it is overkill to create
additional classes if you do not need to. The challenge here, however, is that if you need to obtain results from the query, you're limited because the doWork()method returns void.

Hibernate offers a simple mechanism to execute SQL inside your Hibernate data access object classes by defining a unit of work and passing it to your Hibernate Session's doWork() method. You can define your unit of work explicitly
by creating a class that implements org.hibernate.jdbc.Workor by creating an anonymous inner class that implements the Work interface on-the-fly. The best solution, if you are building your domain
model from scratch, is to model your objects as simply as you can (remember the KISS principle: keep it simple, stupid), but if you have to create a domain model that does not lend itself easily to an object-oriented representation then you can integrate manual
SQL in this manner.