Hibernate vs (EJB or JDBC)

[gilgantic]

When is it better to use Hibernate versus EJB or JDBC? Are there times
we would use JDBC or EJB, and not Hibernate?
I know Hibernate models the architecture of EJB 3.0. What I have
discovered so far is

Advantages of Hibernate over EJB and/or JDBC
==================================
* Entity Beans have to follow naming conventions, POJOs can be any Java
object at all in Hibernate.
* Less code in Hibernate than JDBC
* CMP Entity Beans require a one-to-one mapping to database tables.
* EJB are (by reputation at least) slow.
* Someone has to determine which bean field maps to which table column
in EJB.
* EJB require special method names. If these are not followed
correctly, they will fail silently.
* Entity Beans have to reside within a J2EE application server
environment-they are a heavyweight solution.
* EJB cannot readily be extracted as "general purpose" components for
other applications.
* EJB can't be serializable.
* EJB rarely exist as portable components to be dropped into a foreign
application-you generally have to roll your own EJB solution.

Any links to tutorial, white paper, etc is welcomed.

 

[Marc E]

good question. JDBC seems pretty darn easy to me. why hibernate?

 

[Scott Ellsworth]

When is it better to use Hibernate versus EJB or JDBC? Are there times
we would use JDBC or EJB, and not Hibernate?

Horses for courses. If you have a special requirement, like "we already
bought weblogic 8.0, and it is running on our server. You have to use
it.", then your decision is made. Otherwise, look at the cost of
implementation, the heft of learning, and what your long term goals are.

If you write the sql yourself, which JDBC requires you to do, then
switching to a different dbms can be a pain. Something like HQL may
(not will) wrap that kind of db problem for you.

EJB3 is pretty close to hibernate in many ways, so I will assume you are
asking about 2.1. From what we have seen, many app servers happily
implement code to make EJBs work well, and be monitored. They may not
implement similar monitoring features for Hibernate. Thus, you need to
check your specific app server. Given that the jboss group now funds
hibernate development, I suspect that this is not an issue for JBoss.

From where I sit, I would probably go the Hibernate route for now, as it
can be used with all sorts of deployment strategies, including
standalone apps. EJB requires an EJB container.

Scott

 

[Scott Ellsworth]

good question. JDBC seems pretty darn easy to me. why hibernate?

Isolation. I find that OO programmers tend to work best when working
with Java objects, and tend to write lousy SQL. Similarly, DBAs tend to
write great SQL, and be lousy OO programmers. (There are exceptions
that are good at both - I work with several.)

By using a tool like hibernate, you let the tool do most of the heavy
lifting, and spend your OO programmer's time on the things they are good
at. I would rather spend time modelling the domain into business
objects, and then manipulating those, than messing with the details of a
nasty join or subselect.

That said, if you use a tool like hibernate, you have to watch out for
failures. If it generates bad sql, somebody has to know how to tell
that it is bad, how to optimize it, and how to make hibernate use good
sql instead. Depending on needs, this can be a minor task, or a major
job for someone.

Scott

 

[gimme_this_gimme_that]

Item 1. In today's world of editors that make your getters and setters
item 1 is a non issue.

Item 2. While having less code is an advantage, when you buy into
Hibernate you're not just replacing JDBC, you are investing in a
persistence oriented software system. While Hibernate provides caching
and can allow your application to share millions of objects across
servers, it does not have the flexibility of JDBC. In JDBC when you do
an update it's straightforward (although tedious) to write the code so
that only modified columns are updated. With Hibernate you're locked
into all or nothing.

Item 3. So what's the problem?

Item 4. EJB and Hibernate are mutually exclusive technologies, not
competing technologies.

Item 5. If you are buy into an EJB solution there's probably some
feature of EJB that makes using it a good option. Again, with today's
editors building templates for you special names aren't an issue.

Other items . EJB and Hibernate are not competing technologies they are
mutually exclusive.

In applications where I do a lot of outter join select statements JDBC
leaves Hibernate in the dust.
While it's true that you can get a Connection in Hibernate and then use
JDBC, it's begs the question - then why use Hibernate in the first
place.

Also, if you use Hibernate eventually, as a programmer, you have to get
familiar with it's caching strategies and how it handles instanciation.
I've seen instances where a HQL statement instanciated 1000 objects
which then instanciated 5000 other objects and basically brought the
system to a crawl. Eventually the HQL had to be dropped. But not before
making Hibernate instanciate the objects separetely


BTW, JDBC solutions can be made easy to read.

Spring's JDBC framework makes code easy to read and manages your
connections. It also allows you to build SQL transactions across
multiple data fetches.

 

[Alvin Ryder]

When is it better to use Hibernate versus EJB or JDBC? Are there times
we would use JDBC or EJB, and not Hibernate?

Certainly, I don't want to depend on any 3rd party APIs, sticking to
standard Sun stuff has many advantages.

Now with EJB 3, there is also the Java Persistence API which is POJO
based and it can be used with or without EJBs. I'm finding the case of
Hibernate even less compelling!

Below you compare Hibernate to EJB but one is a persistence API the
other a distributed component API. *Two very different animals*.

And previously rather than Hibernate 2 I had written my own db/jdbc/dao
layer, that code was re-used in many projects. It wasn't a lot of code
either amd I think that was less work than learning Hibernate.

Then for each POJO I just needed to write a small amount Java code
(save/load) which is about the same amount of work as that required for
those Hibernate XML files.

I know Hibernate models the architecture of EJB 3.0. What I have
discovered so far is

(SNIP - we need to compare Hibernate to Java Persistence API not to EJB
3 ;-)

Any links to tutorial, white paper, etc is welcomed.

I recommend Sun's FAQ for EJB 3 and the new Java Persistence API at
their web site. See glassfish while you're there.

Cheers.