Re: Hibernate alternatives

gimme_this_gimme_that_at_yahoo.com
Date: 01/17/05 

Date: 17 Jan 2005 09:50:15 -0800

It's possible to write your code so that you can swap out the
persistence mechanism.

But as far as hibernate is concerned you some alternatives

1. Use hibernate to "store objects". When you do this you write out the
code
to store other objects. If you have a one to many relationship with
another object. You save that object and then save the many
objects.

2. Use hibernate to "store classes". When you do this you have to save
your main
object, attach other objects, and then save. This approach lends
itself to
using HCL. HCL is unlike SQL in that you have to do your joins with
class
members, not on a table.

The advantage of this approach is that it makes the code easy to
read. It
imposses thought into the design process to keep things efficient.
If you
use midgen and your project doesn't get to complicated, it makes it
easy
to add additional members to classes and to database tables.

This disadvantage is that every time you do a query you get an
entire class
(most likely all the data from that table). You also end up getting
involved
with the hibernate scheme for lazy class loading.

There is a significant learning curve to a complete "think
hibernate" solution.

Personally, I think a JDBC solution will always outperform a
hibernate.
It gives you the flexibility to fetch only the information you need
and to
take advantage of joining many tables without having to create
objects
for each row of every table. I think the hibernate people would
claim that
a hibernate solution with a good caching scheme would be just as
fast,
and it may be, but you have to get up to speed on how it all works.