• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate or EJB

 
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ???
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Thomas Whitmore
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
if you think brussel sprouts are yummy, you should try any other food. And this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic