JavaWorld
addict
Reged: 06/20/03
Posts: 482
|
|
A standardized object-relational mapping mechanism for the Java platform
|
Unregistered
|
|
well written article, thanks alot!
|
Unregistered
|
|
Can someone explain to me why are we keep inventing new ORM frameworks every month? Hibernate/POJO/JDO and now this. I am sorry, but for a newbie to this whole data-model-to-object-mapping-sphere, I am a bit confused as to which technology I should turn to. What are the differences between JDO and Java Persistence API? How does one know which to utilize and from what I had gathered, I assumed JDO was a way to standardize the movement!
|
Unregistered
|
|
Quote:
Can someone explain to me why are we keep inventing new ORM frameworks every month? Hibernate/POJO/JDO and now this. I am sorry, but for a newbie to this whole data-model-to-object-mapping-sphere, I am a bit confused as to which technology I should turn to. What are the differences between JDO and Java Persistence API? How does one know which to utilize and from what I had gathered, I assumed JDO was a way to standardize the movement!
I think the multiplicity of mapping models came out of the desire to have standardized ways to persist new classes to corresponding tables in a relational database. This desire was spurred I believe by the preponderance of web based software and the desire to provide rapid development for new changes to tables and types used their in. Around 2000 the designers of such software were really looking for something easier to handle than what was provided by EJB. Separate developer groups tackled the problem for their own needs and came up with the various options available today. I am a software architect and I had to design my own persistence model (coincidentally also based on a superclass called Entity) 5 years ago because at the time no such model existed. After reading this article I am happy that java has finally caught up but there are some aspect to their implementation that seem over complex but it is far better than previous alternatives.
To answer which to turn to, you should turn to the one that allows you to design the most powerful and efficient applications for your needs. If rapid development and change is important you might be enamored of the dynamic query capability in the Java persistence API over Hibernate. Ultimately knowing which is better for you boils down to knowing what you need out of the persistence engine. I had to design my own so I knew precisely what was needed, as such mine isn't as generalized as Hibernate or JPAPI but it does what it was designed to do very efficiently and still allows rapid development , dynamic updates...etc. Choose the persistence model that gives you the over all mix of performance, dynamic changeability and also very important *is easier for you to understand and implement*.
From the little I know of JDO (I only read an article on it a few years after creating my own and it gave me a headache) it supplements EJB persistence. It is container managed persistence as opposed to a global API like JPAPI is.
Here's the sun FAQ on it for your edification: http://java.sun.com/products/jdo/JDOCMPFAQ.html
The major issue that distinguishes use of JPAPI over JDO in my mind is ease of use of the associated EJB elements. JPAPI uses pojo's if you desire allowing you to avoid the clumsy and confusing (at least to me) Entity bean, session bean formalisms of EJB. The main reason why I designed my own persistence model 5 years ago was because looking at the options of the time and EJB gave me serious migranes. I am glad I did as it took java 5 years to get something out that was at least as poweful as what I designed.
JPAPI is basically a more streamlined JDO like model with global use for both EJB and pojo based applications. Much success on your selection choice!
Regards,
sent2null
|