wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes new to hibernate Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "new to hibernate" Watch "new to hibernate" New topic
Author

new to hibernate

Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
I am new to hibernate. i have read the road map and features of hibernate from hibernate.org. but i still want to know something. somebody told me that it is the replacement of entity beans. is it true?
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


somebody told me that it is the replacement of entity beans

No. Its nothing to do with Sun or the JCP. It is a proprietary ORM technology.

However, EJB 3.0 entity beans do currently look like they will be a very simmilar implementation to Hibernate. Entity beans (as of EJB 3.0) look like they will be a copy of Hibernate.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
so, could we go for hibernate instead of ejb. or again there is no relation.

if there is no relation how they are similar and talking about the same stuff. still confused. require more reading, i think. now i can say we can use hibernate and entity beans both together in an application right?

thanx anyways
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


so, could we go for hibernate instead of ejb.

Only if by "ejb" you mean Entity Beans.


if there is no relation how they are similar and talking about the same stuff

Both handle the persistance of objects to an RDBMS. They do the same thing essentially, only one does it far better...


now i can say we can use hibernate and entity beans both together in an application right?

If you wanted to. But I can't think of a situation where it would make any sense to do so.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
so it means it is perfectly right to say that we can use hibernate instead of entity beans.

thanx mates
Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452

Both handle the persistance of objects to an RDBMS. They do the same thing essentially, only one does it far better...



Hi Paul,
Can you tell which one is better and why. I mean better in Performance / Coding / Relaibility. Plz elaborate


Prakash Dwivedi (SCJP2, SCWCD, SCBCD)
"Failure is not when you fall down, Its only when you don't get up again"
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

You've got me in a talkative mood, so here we go:

Hibernate have performance comparison stuff on their website - you can check it out here (if you think performance comparison stuff is in anyway reliable). What I can say is it performs better than Entity beans (caveat: in the context of the applications I have used it on).

Reliability? Yes Hibernate is reliable. Check out their site for a list of outstanding bugs.

Other things:
  • Hibernate is (in general) easier to code than entity beans.
  • HQL is much more useful than EJBQL, and you can use native SQL easily.
  • CMP entity beans are restricted to a one-to-one relationship to ther underlying entities, Hibernate POJOs can span entities.
  • Entity beans tend to become bound to whichever platform you are using, because IBM, BEA et al have written useful extenstensions to fix the failings of Entity Beans which become difficult to avoid using. Hibernate is seperate from container, so its functionality is the same in whatever container you use it in (note: DB platform can still make a difference)
  • You have to use an EJB container with Entity Beans. This is not true of Hibernate (and most other similar ORMs)
  • Entity beans (in their current design) are being killed off by Sun - the new EJB3.0 spec. basically is Hibernate.
  • You can use Hibernate POJO's directly in the client tier. You can't use Entity Beans in the same way - you have to (typically) transfer their properties into value objects first.
  • Hibernate has been designed very specifically to support the features of a properly designed relational model. This is both a good thing and a bad thing. If you are in the position of designing your ER model, Hibernate's restrictions tends to stop you using ugly (or down right wrong) things you see in badly designed ER models (e.g. composite ids, conditional relationships, entites with no PK etc.) Of course, this can make it a little awkward to use with legacy ER models which do have features like this - but you can work round them in the context of Hibernate's archtecture.
  • And I've yet to see a production system which actually uses Entity Beans. (though I'd be interested in hearing if anyone else has used them in production)


  • Of course - a lot of this is just my personal opinion and others may very well disagree. I'd recommend you have a play around with Hibernate and Entity Beans. See which you prefer and get used to the features.
    [ October 13, 2004: Message edited by: Paul Sturrock ]
    Ogi K
    Greenhorn

    Joined: Sep 17, 2004
    Posts: 10
    Entity Beans are dead! If you haven't figured this out by now, you've been out of touch..

    One correction to the above, however, a Hibernate POJO cannot span more than one table at the moment ( neither can entity beans). For this, you'll have to wait for Hibernate 3.

    Cheers.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: new to hibernate
     
    Similar Threads
    hibernate tutorial
    hybernate
    Pagination in Spring and hibernate
    Hibernate Books
    getting data using Hibernate