Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate with DAO?

 
Gaurav Jain
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can i use normal SQL in hibernate instead of using HQL?
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the hibernate docs show how to use standard SQL.
 
Andy Grove
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 108
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    author
    Sheriff
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    author
    Sheriff
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 1646
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 379
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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

    etc.

    Moreover, simply using Hibernate gives you a lot of extra stuff like caching, connection pooling, better SQLs, etc.
     
    Gaurav Jain
    Ranch Hand
    Posts: 108
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Connection pooling will be handled better by the app server rather than hibernate itself..right?
     
    Paul Sturrock
    Bartender
    Posts: 10336
    Eclipse IDE Hibernate Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 108
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 1071
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 108
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 1071
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 33
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 18
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic