CMP or Hibernate?

[roger moon]

Hi,

We will launch a J2EE project where there are two options for the
architecture:
1. Struts -> Session Facade -> DAO -> CMP -> Oracle
2. Struts -> Session Facade -> DAO -> Hibernate -> Oracle

Would any one give some advice about the advange&disadvange of each option?

Thanks,
Roger

[Karan Chandra]

Hi Roger,
Have you find the difference .. I am also bit confused between these to atchitectures.
Can anyone suggest us.
Regards,
Prasad

[Valentin Tanase]

Hi Guys,

In a nutshel I would say that the great benefit of Hibernate relies on its orm capabilities. Hibernate uses XDoclets to generates the persistence layer from a set of standard POJOs. You have a full OO model, using inheritance, polymorphism, encapsulation etc. Entity ejbs uses the abstract schema with its very rigid crm fields, unidirectional and bi-directional relations and the very cumbersome EJB-QL language. At the other end Hibernate employees the whole power of SQL and this can make a lot of difference too. Inheritance sucks with ejbs and the resulting model is not even a great OO design. As from the performances standpoint, ejb might look like a more promising choice, but a highly available and performant ejb persistence framework will involve employing container specific solutions, which will violate the "build once run everywhere" J2EE promise. Not to mention that the risk to fail using entity ejbs is highly greater than using Hibernate. As you can see there aren't many reasons to chose EJB today. However EJB 3.0 is coming and all nice features that you can see today with Hibernate, will be part of entity ejbs. EJBs will actually be POJOs, they won�t implement any EntytyBean or SessionBean interfaces, it will be no remote or home interface, will be no jndi look up and the abstract schema & EJB-QL will be replaced with ORM.
You might also like reading the next post:
https://coderanch.com/t/315684/EJB-JEE/java/Hibernate-Vs-Entity-Beans
Regards.

[Roger Chung-Wee]

Have you evaluated making JDBC calls from your DAO? Many people do it this way, so they do not use entity beans or products like Hibernate.

[Rahul Devgan]

I agree with Roger. What is the need for going for either CMP or Hibernate if you are using the DAO pattern. It abstracts the accession to data from other layers using the same.

[Paul Sturrock]

What is the need for going for either CMP or Hibernate if you are using the DAO pattern

Using DAO and straight JDBC generates a lot of work which could be done by the ORM layer. I wouldn't attempt it without some sort of DAO code generator (this comes from experience - I have done this in the past, and as the need to support more and more databases arrives you can find yourself doing nothing but writing and supporting DAO code). ORMs also often have the advantage that they can come with professional support contracts, which can save you the work of trying to diagnose the very specialized one-in-a-million problems which can occur.