Hibernate with DAO?

[Gaurav Jain]

I am using the DAO pattern for DB access.One way is to directly write SQL in the DAO to access DB.the other is use Hibernate to access DB.
I have never used hibernate but can i use DAO and still use hibernate?
What advantages hibernate provide over the regular DAO feature?

[Paul Sturrock]

Yes you can. Its a good idea too - in this case the DAO pattern will keep the actually implementing ORM technology in its own layer. If you suddenly decide you hate Hibernate, you could swap to a JDO implementation without impacting your application (beyond having to write DAOs for JDO...).

The advantage Hibernate gives you in this case is you no longer need to worry about platform-specific SQL.

[Gaurav Jain]

Can i use normal SQL in hibernate instead of using HQL?

[Steven Bell]

Yes, the hibernate docs show how to use standard SQL.

[Andy Grove]

I would definitely recommend using the DAO pattern in front of Hibernate.

Using DAO has several advantages:

Enforces good separation of business logic and data

Allows you to move persistence code from Hibernate in the future

Easier to expose DAO objects in SOA or Web Service environment

You might find this article on data access objects useful. It talks about using the DAO design pattern with an ORM approach.

[Gaurav Jain]

I am still not convinced that how hibernate is more advantageous over DAO especially when you talk about in excess of 250 tables.According to my understanding in hibernate each table is mapped to a POJO that means you will end up creating 250 POJO's and i am not sure how many config files will be created.
I am yet to find out a sure shot winner in terms of hibernate...

[Lasse Koskela]

Originally posted by Gaurav Jain:
According to my understanding in hibernate each table is mapped to a POJO that means you will end up creating 250 POJO's and i am not sure how many config files will be created.

Hibernate supports table-per-class-hierarchy, table-per-class and table-per-subclass strategies for dealing with inheritance. With this in mind, and knowing that Hibernate also supports association tables for many-to-many mappings, what's left that you could get rid of with hand-written DAO's?

[Lasse Koskela]

By the way, even if you're using Hibernate, it's still a good practice to wrap the Hibernate code inside a DAO. In other words, I'm assuming that by "DAO", you're referring to "DAO-with-hand-written-JDBC".

[David Harkness]

Originally posted by Gaurav Jain:
I am still not convinced that how hibernate is more advantageous over DAO especially when you talk about in excess of 250 tables.According to my understanding in hibernate each table is mapped to a POJO that means you will end up creating 250 POJO's and i am not sure how many config files will be created.

If you used DAOs with hand-coded JDBC, where would you store the results for passing to the client? Wouldn't you create POJOs for this anyway?

[Sathya Srinivasan]

Originally posted by Gaurav Jain:
I am still not convinced that how hibernate is more advantageous over DAO especially when you talk about in excess of 250 tables.According to my understanding in hibernate each table is mapped to a POJO that means you will end up creating 250 POJO's and i am not sure how many config files will be created.
I am yet to find out a sure shot winner in terms of hibernate...

First, you don't have to write 250 classes if you are not using all the 250 tables. You can selectively map only the tables you need and write POJOs for them.

Second, as was mentioned in a previous reply, each table does not have to map to a class. You can map multiple tables to a single class depending on your need using the join tag in Hibernate 3 or based on class hierarchy.

The advantage of hibernate is that you don't have to write code such as

 object.setAttribute(resultSet.getString(1);  

etc.

Moreover, simply using Hibernate gives you a lot of extra stuff like caching, connection pooling, better SQLs, etc.

[Gaurav Jain]

Connection pooling will be handled better by the app server rather than hibernate itself..right?

[Paul Sturrock]

Hibernate doesn't supply any Connection Pooling (it is just an ORM layer). You can use a Connection Pool implementation supplied as part of an application server, or you can use a stand alone Connection Pool implementation as suits.

[Gaurav Jain]

I understand that hibernate generates HQL in the background.If i need to fine tune my SQL queries then how do i do them since those are HQL's generated by hibernate although tuning is possible if the developer writes the normal SQL himself.

[Steven Bell]

Originally posted by Gaurav Jain:
I understand that hibernate generates HQL in the background.If i need to fine tune my SQL queries then how do i do them since those are HQL's generated by hibernate although tuning is possible if the developer writes the normal SQL himself.

I don't think that is correct. You can write HQL that hibernate will parse and turn into SQL to run against the DB. I don't think hibernate will modify SQL when it is passed in, if it did I would wonder what could possibly be the reasoning behind it. It would have to take SQL, convert that to HQL, and then convert that back to SQL.

P.S. Hibernate does provide connection pooling, but it's implementation is not recommended for production apps, it does ship with alternative connection pooling libraries you can use with a bit more work.
[ March 01, 2005: Message edited by: Steven Bell ]

[Gaurav Jain]

I dont think you can write HQL yourself..that is the advantage of using hibernate as it itself generates HQL to make it DB independent hence the question of SQL tuning.

[Steven Bell]

Originally posted by Gaurav Jain:
I dont think you can write HQL yourself..

HQL is the query language that you write and pass to hibernate so you don't have to write SQL.

This is HQL. It is hibernates query language. You write in HQL so hibernate can convert that HQL into DB specific SQL with one of it's 'dialects'.

I was a little off in my understanding of native SQL in hibernate, but all it does is replace some identefiers with the correct table names as shown here.

[Thomas Whitmore]

How about we use Data Access Services as the term rather than DAO. DAO refers originally to one-object-per-managed-instance 'peers' which are rather unnecessary.

What you really want is a Service Facade like eg.

CustomerMgr
Customer getCustomer (Object id)
Object getCustomerId (Customer cust)
void storeCustomer (Customer cust)
void deleteCustomer (Customer cust)
...
List searchByName (String prefix)
List listByRegion (String region)
...

Service Facade can be implemented with JDO, JDBC, HB or literally *any* backend behind it. For JDO or similar managed solution the methods are pretty much one-liners, but this is all it takes to achieve the full modularity and design benefits.

The principle here, is KISS - all you need is a point of control where you can control caching or application requirements, change implementation etc.

And this is the exact correct design to implement these, when and should you need to. Until then, it's just a direct logical handle on what the app requirements.


Cheers,
Thomas
www.powermapjdo.com

[Andy Grove]

You can use service oriented facades very easily with the DAO design pattern. In fact, FireStorm/DAO can generate a service facade in front of your DAOs (which can be based on EJB, JDO, JDBC, Hibernate, etc.)

The service facades can easily be exposed as Session Beans, Web Services, and so on.