Integrating JDBC with Hibernate
Integrating JDBC with Hibernate
from http://www.informit.com/guides/content.aspx?g=java&seqNum=575
Last updated Jun 25, 2010.
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:
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 new MyWork 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 extending HibernateDaoSupport, 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 a Statement, 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.Work or 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.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.