wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes Hibernate or EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Hibernate or EJB" Watch "Hibernate or EJB" New topic
Author

Hibernate or EJB

Giju George
Ranch Hand

Joined: Jun 08, 2004
Posts: 333
We are in the process of developing a shopping cart application which needs lot of tx etc. I have heard about Hibernate, but don't know exactly about it. What's are the major differences between hibernate and EJB and what do u guys suggest using for a shopping cart application.. and why ???


SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCEA
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Well, it is like comparing Apples to Oranges, yes there might be some basic sort of overlap, but they are two different things.

Hibernate is a Relational Mapping tool. Meaning a transparent persistence mechanism that can be used in any application to decouple Data Access from Business Logic.

EJB is a specification, standard. It isn't exactly a tool. Yes there are APIs but.

Basically the way that it overlaps is in EJB CMP Entity Beans as a way of saving data, versus a cleaner, less coupled, and more manageable way of saving data with Hibernate.

So the question is how far do you want to decouple and be more transparent. If it is more than less, then Hibernate will be a better choice. If you don't care and have EJB experts and CMP will be fine for you for performance then stay with CMP, or even BMP if you want to write all that JDBC code, and the maintenance needed for that.

Hope that helps.

Mark


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

Joined: Aug 05, 2004
Posts: 33
Hi George,

You should also check out JDO, this is the standard for OO data access and especially if you have to connect different databases or need portability this will help you down the line.

These are also more modern and use a simpler/ more efficiently structured design than EJBs. EJBs takes a lot of dev work, are slow to test (need to wait for deployment every time) and tend to get bogged down at fine-grained detail such as OrderLines.

(Sentence remove by Mark Spritzler)


Cheers,
Thomas Whitmore
www.powermapjdo.com
[ September 11, 2004: Message edited by: Mark Spritzler ]
Edward Kenworthy
Ranch Hand

Joined: Oct 05, 2003
Posts: 66
Originally posted by Giju George:
We are in the process of developing a shopping cart application which needs lot of tx etc. I have heard about Hibernate, but don't know exactly about it. What's are the major differences between hibernate and EJB and what do u guys suggest using for a shopping cart application.. and why ???


I infer from your question that you are looking for a persistence solution. EJB is not a persistence solution. EJB best practice is that the last thing you want to use are entity beans: they are awful. CMP beans are deadweights that impose a lot of overhead for next to no useful benefit and if you're using BMP beans you have a similar overhead: plus you have to code all the persistence by hand anyway.

My personal EJB best practice is to never use them (and yes I know EJB 3.0 but having worked through 1.0, 1.1 and 2.0 I have little confidence that 3.0 is going to change much before it comes out and will just be playing catch up with best practice elsewhere: it's being designed by committee: 'nuff said.)

There are only 3 reasons to use EJB: 1) You need to support remote Java clients using RMI/IIOP 2) you need Message Driven Beans 3) you're a masochist.

Why do I say that? Because EJB is very invasive (try running an EJB bean anywhere except in an EJB container) it even invades the client (JNDI lookup, remote exceptions), because it has heavy-weight run-time requirements, because it kills any chance of applying good OO design and finally because almost all the benefit people think they're getting from EJBs (eg connection pooling) are actually provided by the J2EE server.

Have a look at using a lightweight framework (eg www.springframework.org) plus an ORM mapping tool (Hibernate is a good, widely used and free as in beer and speech). I've only used Hibernate for simple stuff: but let's face it, simple stuff when it comes to using a database is all the vast majority of us do unless interacting with legacy systems.

Edward

PS

One last thought: why develop yet another shopping cart application? Have you considered using an existing one and tailoring it?

[ August 12, 2004: Message edited by: Edward Kenworthy ]
[ August 12, 2004: Message edited by: Edward Kenworthy ]
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Though I agree with your sentiments about Entity Beans, I have to pick up a few points:

try running an EJB bean anywhere except in an EJB container

Ehm...why would you do this? EJBs are specified to run in a container. So:

almost all the benefit people think they're getting from EJBs (eg connection pooling) are actually provided by the J2EE server

is exactly as I'd expect. The container provides the common services, which an EJB can use. Why would you use an EJB containers without EJB?


There are only 3 reasons to use EJB: 1) You need to support remote Java clients using RMI/IIOP 2) you need Message Driven Beans 3) you're a masochist.

What about clustering? Declarative security? Distributed transaction management? Well-understood design patterns and framework? etc.


but let's face it, simple stuff when it comes to using a database is all the vast majority of us do unless interacting with legacy systems

Speak for yourself. Applications backed by large, complex schemas stored on multiple platforms is the norm where I work. I'd suggest the opposite is true - if all you are doing in "simple stuff" what's wrong with JDBC?


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Robert Chisholm
Ranch Hand

Joined: Jul 18, 2004
Posts: 69
Ed,

Just curious if you have used SLSB (stateless session beans). To me they seem like a fairly painless way of getting the benefits of the EJB container without a lot of the baggage...

I have read many negative stories about entity beans, so my current project is using a DAO on the back end (which may or may not use Hibernate), and a session facade between the DAO and the client (I have server-side and remote clients).


SCJP 1.4<br />(WIP) SCJD B&S v2.3.3
Thomas Whitmore
Ranch Hand

Joined: Aug 05, 2004
Posts: 33
Hi Ed, Paul, Robert,

Good comments on Entity Beans and the associated overhead.


Re: try running an EJB bean anywhere except in an EJB container

The reasons Ed might want to do this, would be to speed up and simplify his testing/ debugging cycle. Doubling your productivity is fun. Halving it is not. Having to jump thru hoops even to interactively debug your code is just poor; this ain't the days of line printers.

The amount of build overhead necessary for packaging, deployment, container loading, classfile mangling, and page recompilation is enormous and thoroughly intrusive into the development cycle. 'Halved productivity' is probably being generous.

Re: almost all the benefit people think they're getting from EJBs (eg connection pooling) are actually provided by the J2EE server


is exactly as I'd expect. The container provides the common services, which an EJB can use. Why would you use an EJB containers without EJB?

Clustering, Distributed Tx, and enterprise apis such as Messaging/ Mail etc are great. But you wouldn't want to touch Entity Beans with a forked stick.


What about clustering? Declarative security? Distributed transaction management? Well-understood design patterns and framework? etc.

Declarative security is partially OK. As in, OK for the most basic stuff and then not extensible for full-weight application security requirements.

Well-understood design patterns and frameworks? I believe Edwards understands these well, in a framework of avoiding these where possible...
:-)



Applications backed by large, complex schemas stored on multiple platforms is the norm where I work. I'd suggest the opposite is true - if all you are doing in "simple stuff" what's wrong with JDBC?

Many people's conclusion is that EJBs aren't right for the simple stuff, but that EJBs don't do well for the hard stuff either. (Backend mapping, relationships, inheritance, etc).

Session Beans (stateful or stateless) are the major part that *does* work and you can build a strong application with these in conjunction with a JDO or other non-ejb data layer. This gives a fundamentally more correctly structured architecture and can still participate in distributed tx, etc if needed.


Cheers,
Thomas Whitmore
www.powermapjdo.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Hibernate or EJB
 
Similar Threads
Shopping Cart in Session?
web project
Personal project
Server Session pattern
Model View Controller