OJB provides much more flexibility in caching; provides object-space transactions in a non-managed environment (if you are running in a J2EE container which provides JTA than this is probably a wash as you will probably want to use JTA for transactions and both OJB and Hibernate support using JTA); allows non JavaBean accessors (Hibernate uses getFoo()/setFoo(...) for all persistent field access, OJB can do that, or access fields directly, or access DynaBean properties, or figure out which one is being used for which field and choose the correct method, or you can implement a new field access strategy (it is pretty easy); it can access non-relational data sources (pretty minor for most people, but it is a good example of the flexibility), it supports more than one API (the PB kernel (proprietary), ODMG 3.0 (published standard), OTM (proprietary), JDO 1.0 (published standard) compared to HQL (proprietary) and a promise to support JDO 2.0 whenever it is actually specified), and these can all politely interoperate; pretty much every important thing it does is pluggable so you can get the exact behavior you need -- for instance the use of the per broker cache allows you to use domain objects as transfer objects directly as once they are non-transactional they can no longer effect the domain or others using the same entity -- this is a particularly handy flavor I have found as it allows you to *not* implement yet-another-layer for TO's); pluggable strategy for handling sequences (id, autogenerated PK fields); and it goes on. The biggest thing is a core design difference where OJB is designed to be very flexible and allow you to get exactly what you need whereas Hibernate is designed to do it one way and make that one way match what most people need. Finally, the licensing issue is either a huge difference or a doesn't-matter depending on your company's lawyers and/or how you intend to distribute the application -- OJB is ASL Hibernate is LGPL.
On the other hand Hibernate provides two things that OJB does not -- a forthcoming book and the ability to easily hand it a JDBC Connection and have it use that Connection (this can be done via some voodoo-like runtime configuration of OJB, but isn't a good idea -- OJB pretty much needs to know the JNDI lookup for your DataSource in its configuration). In a J2EE environment this is fine in a non-managed, non-jndi it is fine 99% of the time.
On the docs thing -- yes, Hibernate has stronger docs right now. I am actively working to improve OJB docs and plan on having what amounts to a completely new set of tutorials (three of four are in CVS right now) and reorg of the existing to make it easier to use by the end of November.
-Brian
On Tuesday, November 4, 2003, at 02:41 AM, Florin Pop wrote:
Hi there,
we are in the situation of choosing one persistence framework for a J2EE
project. The finalists are Hibernate and Apache's OJB, not necesarily in
this order. Can you give me some hints about what OJB does better and (if
possible) what does worse ;)
My first impression is that Hibernate is easier to work with. So from this
point of view Hibernate is the winner. Also considering the documentation,
the one for Hibernate is more intuitive and more complete, the one for OJB
seems(is) unfinished.
But I was wondering if there are any "hidden" things such caches,
transactions, locking or any other performance issues which work better on
one of the 2 tools.
Unfortunatelly the time is short and we do not have time to test too much.
Thanks for your feedback,
Florin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PGP.sig
Description: This is a digitally signed message part
