Hibernate alternatives

Z

Zsolt

Hi,

we plan to use hibernate but before that we want to check whether there are
alternatives to it or is it defacto standard?
 
D

Daniel Rohe

Possible alternatives are all persistence mechanism. There could be plain
old SQL abstracted with a DAO layer, one of the JDO implementations, another
ORM-solution or maybe EJB. Without more knowledge about limitations in your
project it is hard to suggest an alternative.

Greetings
Daniel
 
Z

Zsolt

We develop a web application. Right now, we use dbcp (database collection
pool) and use JDBC directly.
 
R

Rico

Hi,

we plan to use hibernate but before that we want to check whether there are
alternatives to it or is it defacto standard?

You might want to use 'standard' loosely here.

Rico.
 
D

Daniel Rohe

Hibernate is not the de facto standard! It is a well known and good solution
of a persistence mechanism. Alternatives are for example OJB, Torque, etc.
More open source alternatives are listed under [1].
If you want to be independent from the persistence mechanism you have to
implement a DAO layer, which abstracts from the persistence mechanism. With
this layer your application can use any possible persistence mechanism which
is on the market. You must then provide a implementation of that layer with
the specific persistence mechanism. A description of the DAO pattern can be
found under [2].

[1] http://java-source.net/open-source/persistence
[2]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Greetings
Daniel
 
C

Chris Smith

Daniel Rohe said:
Hibernate is not the de facto standard!

No, certainly not. The field is very open. Hibernate is far more
popular than anything similar that's out there, but I suspect many times
as much code is written in plain JDBC as that written for Hibernate.
If you want to be independent from the persistence mechanism you have to
implement a DAO layer, which abstracts from the persistence mechanism. With
this layer your application can use any possible persistence mechanism which
is on the market.

I disagree with this advice. Unless your application's persistence
requirements are trivial, it will be nearly impossible to design an
abstract persistence layer that can be implemented interchangably using
something as distinct as, say, Hibernate versus JDO. The basics may fit
together, but the differences in transaction semantics and the like will
kill you. You either:

1) End up effectively committing yourself to one product anyway; except
you don't know it.

or 2) Commit yourself to developing in such a horrid distortion of Java
that you've lost the very thing that makes O/R mapping popular anyway.

Either way, you've put in a substantial portion of the work you would
have needed to roll your own persistence anyway, you've created a large
body of code to maintain (and since the code is dependent on the
external interfaces of potentially several products, it will change MORE
than the simpler code), and you've opened up the possibility of who
knows what subtle bugs in the future.

Nah. Better to just pick a product and write to it. If you change your
mind later, do the port then.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
A

AlexKay

Zsolt said:
Hi,

we plan to use hibernate but before that we want to check whether there are
alternatives to it or is it defacto standard?

Personally I just prefer to write my own using plain old OOP. It just
isn't that hard.

Currently the ORM/DB/CRUD/ACID stuff represents something like 3 to 5%
of my projects. It's important but only a minor part of the effort.
Furthermore, when I start using Java 1.5 and generics it'll be even
less code.

Current project is 40,000 lines of code so far, of which 1000 lines
(3%) is db/crud/acid.

I reckon if I used something like Hibernate I'd have more than 1000
lines of XML mapping files and who knows how much extra mucking around?

Previous project, 180k lines, about 10k (5%) was db stuff. It was more
complex and also did more advanced stuff like versioning, cloning,
variations, etc etc.

I'm not sure if things like hibernate can even do all of those things?

Anyway, for me at least, there is no attraction to creating a
dependancy on any of those 3rd party products.
Oh well, each to their own.
Alex K
 
H

huy

Chris said:
No, certainly not. The field is very open. Hibernate is far more
popular than anything similar that's out there, but I suspect many times
as much code is written in plain JDBC as that written for Hibernate.

If you like controlling your SQL, then ibatis sqlmaps is my option over
hibernate. It's a bit easier to get started with as well IMO.
If you want to be independent from the persistence mechanism you have to
implement a DAO layer, which abstracts from the persistence mechanism. With
this layer your application can use any possible persistence mechanism which
is on the market.


I disagree with this advice. Unless your application's persistence
requirements are trivial, it will be nearly impossible to design an
abstract persistence layer that can be implemented interchangably using
something as distinct as, say, Hibernate versus JDO. The basics may fit
together, but the differences in transaction semantics and the like will
kill you. You either:

[...there was more...]

You can use the spring framework (www.springframework.org) to implement
a cross product DAO layer which would centralize as well as minimize any
future need to change persistence implementations. It really is quite
uniform the way they support Hibernate, SQLMaps, JDO, JDBC etc. You can
mix a match persistence implementations cleanly as well in the one
application. The declarative transactions are also a huge advantage.

Regards,

Huy
 
G

gimme_this_gimme_that

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.
 
D

Daniel Rohe

Chris Smith said:
I disagree with this advice. Unless your application's persistence
requirements are trivial, it will be nearly impossible to design an
abstract persistence layer that can be implemented interchangably using
something as distinct as, say, Hibernate versus JDO. The basics may fit
together, but the differences in transaction semantics and the like will
kill you. You either:
1) End up effectively committing yourself to one product anyway; except
you don't know it.

or 2) Commit yourself to developing in such a horrid distortion of Java
that you've lost the very thing that makes O/R mapping popular anyway.

Either way, you've put in a substantial portion of the work you would
have needed to roll your own persistence anyway, you've created a large
body of code to maintain (and since the code is dependent on the
external interfaces of potentially several products, it will change MORE
than the simpler code), and you've opened up the possibility of who
knows what subtle bugs in the future.

The OP doesn't say anything about the transactional behaviour of the
application, so I think just thinking about the abstraction from the
persistence mechanism is a good advice.
He said his application uses JDBC, maybe SQL statements in JSPs. So my
advice is to first encapsulate the JDBC stuff in Java objects and use the
Java objects in the presentation layer. After that he can think about using
another persistence mechanism. If he has a object model and uses JDBC then
there could be something like a DAO layer.
With an abstraction from the persistence mechanism he can use his current
JDBC implementation with older products and use for example a new hibernate
implementation with new products. Later he can switch for example to a new
JDO implementation.
In one running application there will be only one persistence mechanism, not
for example hibernate and JDO at the same time. The abstraction layer is
only there that he doesn't have to change the business and presentation
logic of his application when a customer wants to use hibernate or JDO
because he has heard sooo much good things about it.
Nah. Better to just pick a product and write to it. If you change your
mind later, do the port then.

The OP wants to port from JDBC to a persistence mechanism. What about the
costs of supporting the current JDBC solution after porting the application?
How much does a bugfix cost with abstraction from persistence mechanism and
without abstraction? What about the cost of maintaining two development
streams: one for supporting older implementation with JDBC and one for new
implementations with another persistence mechanism?

Greetings
Daniel
 
Z

Zsolt

We have some complicated queries (for example we join sometimes 10 tables)
and some programmers do have problems with for example outer joins, thus we
think it would be better to work primarily with java classes.

We have a also simple caching that keeps all results in memory until an
INSERT, UPDATE or DELETE is executed, however we need a better one because
sometimes to clear the entire cache because something simple was stored into
the database is not effective.

Zsolt

huy said:
Chris said:
No, certainly not. The field is very open. Hibernate is far more
popular than anything similar that's out there, but I suspect many times
as much code is written in plain JDBC as that written for Hibernate.

If you like controlling your SQL, then ibatis sqlmaps is my option over
hibernate. It's a bit easier to get started with as well IMO.
If you want to be independent from the persistence mechanism you have to
implement a DAO layer, which abstracts from the persistence mechanism.
With this layer your application can use any possible persistence
mechanism which is on the market.


I disagree with this advice. Unless your application's persistence
requirements are trivial, it will be nearly impossible to design an
abstract persistence layer that can be implemented interchangably using
something as distinct as, say, Hibernate versus JDO. The basics may fit
together, but the differences in transaction semantics and the like will
kill you. You either:

[...there was more...]

You can use the spring framework (www.springframework.org) to implement a
cross product DAO layer which would centralize as well as minimize any
future need to change persistence implementations. It really is quite
uniform the way they support Hibernate, SQLMaps, JDO, JDBC etc. You can
mix a match persistence implementations cleanly as well in the one
application. The declarative transactions are also a huge advantage.

Regards,

Huy
 
S

Scott Ellsworth

Zsolt said:
We have some complicated queries (for example we join sometimes 10 tables)
and some programmers do have problems with for example outer joins, thus we
think it would be better to work primarily with java classes.

Check out Cayenne. We have used it on occasion.

We wrote our own persistence layer as well, and it is not an easy thing
to do well. I strongly recommend trying Hibernate, Cayenne, and a few
others, before deciding to burn the time to write one.

Scott
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Hibernate foreign key as primary key 9
Netbeans ireport hibernate 0
Spring/hibernate and JDBC 35
Hibernate 1
Anaconda Alternative Question 1
Hibernate + java 1
Hibernate Validator Date 0
Hibernate or JPA? 2

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top