aspose file tools*
The moose likes Object Relational Mapping and the fly likes When should an OR mapping framework be used? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "When should an OR mapping framework be used?" Watch "When should an OR mapping framework be used?" New topic
Author

When should an OR mapping framework be used?

John King
Ranch Hand

Joined: Aug 27, 2002
Posts: 165
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 ]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
John King
Ranch Hand

Joined: Aug 27, 2002
Posts: 165
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
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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

Joined: Aug 27, 2002
Posts: 165
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?
Pj Murray
Ranch Hand

Joined: Sep 24, 2004
Posts: 194
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 ).


PJ Murray -
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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

Joined: Aug 27, 2002
Posts: 165
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
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

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

Joined: Aug 27, 2002
Posts: 165
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: When should an OR mapping framework be used?