EJB 3.0 Persistence API and Hibernate.

[amitesh kumar]

Hi all,
I have to decide on the usage of technology to be used on a new project. My PM has given me 3 options to chhose from:
1. Java + Java Persistence API
2. Java + Java Hibernate
3. C# + ADO.NET


Will someone help me in exploring the differences in the 3 different object persistence options available i.e. Java Persistence API, Hibernate and ADO.NET. The selection totally depends on the persistence API as this is the key to the project.

[Dibbo Khan]

Since I am a C# consultant, I can cast some light on the third option. There is an interesting away of handingly data persistence issues in C# by using strongly typed datasets. This is using ADO.NET datasets but based upon the schema a strongly typed table and row will be generated for you simplifying the database development?

The strongly typed datasets are generated by the Visual Studio IDE when you drag data tables onto an .xsd file.

[Charlie Havener]

For Java Persistence do you mean the built in XML persistence in the java beans package that was introduced in JDK 1.4? If so, I highly recommend it. See my paper on it, a link is on my web site http://www.cdhconsult.com

However, you have not given enough information. Do you have to query the data you save? If so you may need a relational DB. What about speed, does it have to be very fast on save and restore or does it not matter much?

Charlie

[Keith Weinberg]

Option #2 is probably the safest. This will allow you to develop your app without any reliance on EJB containers/etc and your code will not be dealing with bleeding-edge technologies. Since the new Java Persistance is based somewhat on Hibernate, it will be _very_ easy to port your code to option #1 if you decide to and when you feel comfortable with EJB3 containers.

On a side note, if this is a web app, I would _highly_ suggest mixing the following frameworks:
Hibernate (for database persistance)
Spring (for configuration management and transaction management of hibernate -- NOT for web-pages though).
Webwork (for the web side -- this will eventually be Struts 2, so it is a safe and elegant option).

And you should also look at using the "displaytag" component for drawing your data-tables.

You can look at "appfuse" for an example of using all of these technologies together -- These tools together are the most powerful stack I've used.

/<

[Jeroen T Wenting]

Instead of Webworks, JSF is most likely a better option.
It's standardised, directly supported by Spring, and lightweight.

If Webworks is anything like Struts you want to stay far away from it.

[Mike Keith]

Option #2 is probably the safest. This will allow you to develop your app without any reliance on EJB containers/etc and your code will not be dealing with bleeding-edge technologies. Since the new Java Persistance is based somewhat on Hibernate, it will be _very_ easy to port your code to option #1 if you decide to and when you feel comfortable with EJB3 containers.

This is a very strange response. Why would somebody pick a proprietary solution over a standard and think it is the safest? Writing to the standard is clearly the safest option, and then you have the flexibility to use whatever implementation underneath, being that all the major implementations (including Hibernate) are implementing it. Binding your application to a properietary API is exactly the problem that JPA was designed to solve, so if you end up choosing Java to build a new application then using JPA is a no-brainer. It is the existing applications with investment in other technologies that have a more difficult decision.

-Mike