• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When should an OR mapping framework be used?

 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm working on a web app which has about 10 tables. Should I use a OR mapping
framework (JAP, JDO, or Hibernate) or just JDBC?
[ November 11, 2007: Message edited by: John King ]
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well you could use either. How many queries do you need to write. Do you want to deal with JDBC at all? do you have ORM experience where you find it quicker than JDBC? Would you rather handle the DB = Object mismatch in a cleaner way, then you use an ORM tool.

Personally, even in small apps, I always choose ORM, but that doesn't mean that JDBC in some of those small apps is a bad choice.

Mark
 
John King
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is not just that Hibernate (or JDO, JPA) is new for me. The performance overhead introduced by ORM framework has to be considered also.

Has anyone done any analysis on this?
[ November 14, 2007: Message edited by: John King ]
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John King:
It is not just that Hibernate (or JDO, JPA) is new for me. The performance overhead introduced by ORM framework has to be considered also.

Has anyone done any analysis on this?

[ November 14, 2007: Message edited by: John King ]



OK, here is my comment on "performance overhead". If you know the ORM tool and everything it has to enhance performance, you can in many cases make Hibernate or other ORM run faster than straight JDBC code.

Now it is not always the case, but "performance overhead" is never a consideration for me in deciding to use an ORM tool, ease of maintenance time to code is a consideration for me that ORM totally beats the head with a stick on JDBC. But I don't think people are bad or wrong if they do take "performance overhead" into consideration. For instance I wouldn't use ORM in a J2ME app, but then J2ME app usually don't store much data.

Mark
 
John King
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Spritzler:

... you can in many cases make Hibernate or other ORM run faster than straight JDBC code.
...



Hibernate is built on JDBC. How can you make Hibernate over perform direct JDBC?
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by John King:


Hibernate is built on JDBC. How can you make Hibernate over perform direct JDBC?



You can't, of course! (Assuming you write perfect Hibernate and perfect JDBC code - a big assumption). Perfectly optimized Hibernate will always be slower than perfectly optimized JDBC.

As you point out, Hibernate is a layer on top of JDBC. For some reason, this is an area of huge sensitivity for Hibernate fans (I've no idea why.....)

But in how many people can write JDBC code that is perfectly performance-optimized? How many people can afford the time to write perfect JDBC code?

And in how many projects is the data persistence layer performance really so important that the (often slight) Hibernate overhead makes any difference?

If your organization has already standardized on Hibernate then for consistency and lower maintenance costs it makes sense to use it in all projects (unless performance REALLY is that important, but then there are faster options than JDBC like SourcePro DB ).
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by PJ Murray:


You can't, of course! (Assuming you write perfect Hibernate and perfect JDBC code - a big assumption). Perfectly optimized Hibernate will always be slower than perfectly optimized JDBC.

As you point out, Hibernate is a layer on top of JDBC. For some reason, this is an area of huge sensitivity for Hibernate fans (I've no idea why.....)



It is really simple why, and the reason why it is a "huge sensitivity for Hibernate fans" is that when someone says that it can't ever run faster than JDBC simply doesn't understand Hibernate or know everything that it has, you simply look at it as a layer above JDBC and that is only a third of what Hibernate is.

So Hibernate has first and second level cache's, so that in many cases in application, you don't even need to go to the database, whereas with JDBC you will have to go to the database each time you need to run a query. So if I have a query that gets the results (up to date too) from in memory versus a JDBC call to the database, I am pretty 100% sure that Hibernate will run faster than JDBC.

You could write a third of a Manning book called "JPA Persistence with Hibernate" on querying/loading techniques alone, that can and will make Hibernate faster than JDBC.

I am not saying in all scenarios that Hibernate is always faster than JDBC, but I am saying that you can make Hibernate run faster than JDBC in certain situations, and that Hibernate has a steep learning curve to fully understand all the nuances and performance enhancements that Hibernate has over JDBC. But that it can and has been done many times over.

Mark
 
John King
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When you write a DAO using JDBC, you should also use cache to reduce
unnecessary DB calls, just like Hibernate does.

Hibernate is more complex than JDBC. If a programmer could not code
JDBC well, he/she probably could not code Hibernate well also.

I believe that Hibernate does make mapping much more clear than JDBC, which
would help you to maintain your DAO classes, especially when you using
a large DB.

I do not think Hibernate helps much on transaction management.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So John with JDBC and Cache, do you really want to write all that caching code yourself, same with transaction code and also your conversion code from ResultSet to Java OO Objects and back, and also code the opening and closing of Connections (which leads to forgetting to close them and get memory leaks) yourself, or let a tool that works incredibly well, do it for you.

Personally, I would never want to have to deal with the mess and maintenance of JDBC ever again in my life.

Mark
 
John King
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Caching in DAO depends on application logic, not all the DAO need caching.
It is easy to code caching if it is only for a specific logic need.

Converting ResultSet to Object is annoying, but straight and simple.

DataSource handles opening and closing DB connections, not in DAO.
 
reply
    Bookmark Topic Watch Topic
  • New Topic