This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
hi Guys, i am new to Hibernate and JDO, in my current Project we r going to use these techonologys, some one says Hibernate is good, Jdo is Not Good,i have a small Confusion is there between these two thinks, which is Best one, i my Project nearly 200 tables are ther,
Hibernate and JDO are both technologies for object-relational mapping. A major difference between the two is that Hibernate is an ORM product while JDO is an ORM specification (implemented by many JDO products).
If you have 200 tables, then you may be better off just generating your data persistence tier rather than manually doing 200 mappings.
The advantage of generating the persistence code rather than using a graphical mapping tool (or even writing XML mappings) is that you can simply regenrate in a few seconds if you make changes to the database schema.
With regard to the choices:
-JDBC DAOs - Data Access Objects are a core J2EE design pattern - so it's a sound approach (provided you're not hand-writing the DAOs!). The most simple solution with the shortest learning curve. No runtime/deployment fees.
-EJB CMP - often must be used in projects because everything has to be written for a J2EE app server. Not so bad if you're generating the code. Most J2EE products have runtime/deployment fees.
-JDO - the best data persistence specification. Problems with politics - even if the JCP vote on JDO 2.0 goes well, the specification has been damaged (which was the intention of the J2EE vendors that voted against it, I suppose). Using mapping tools for 200 tables would be a bit of a drag - but JDO is ideal for code generation so you can have your JDO code in a few seconds. Some JDO implementations have runtime/deployment fees.
-Hibernate - without doubt where the market momemtum is. Remember this is a proprietary product - but you get the source code so you'll never really be stuck. No runtime/deployment fees.
I should point out that CodeFutures supports all off the 4 options above so we're pretty neutral regarding the data persistence strategy.