+1.
I've had the "opportunity" lately to work on a largish project (700+
classes, 79 entity classes; over 100 tables result from the mapping)
that is done with hibernate POJO.
To a certain extent, any project with that many entities and tables
can be a pain to manage and work with, but hibernate provides it's own
special level of hell when it comes to debugging.
When things "work", life is great, but when they don't work, I lose
hours trying to figure out what hibernate is doing under the hood.
Recent example was a class cast exception caused by hibernate fetching
an object based on its superclass, but the resulting object was a
hibernate proxy, so a particular assignment, which looked reasonable
and which worked in 90% of the cases, failed (incidentally, in a POJO
model, there are good reasons to use proxies in many situations).
Frankly, I find Cayenne's inheritance model much /easier/ to
understand and debug than hibernate's POJO model. Granted, just
because hibernate's POJO implementation sucks doesn't mean that
cayenne's has to, but I think the POJO bit is mostly* overrated.
Robert
*I have enjoyed Tapestry 5's "POJO" approach to development, but even
there, I enjoy it more as a committer, for the flexibility it affords
in evolving the framework, than as a user. The only real bonus as a
user is that autocomplete works a lot better since the only methods in
the class are the ones I've defined, rather than a bajillion
superclass methods. ;)
On Nov 19, 2009, at 11/198:11 AM , Michael Gentry wrote:
On Thu, Nov 19, 2009 at 7:56 AM, Andrus Adamchik <[email protected]
> wrote:
No question, this can be useful. Where this gets in the way is with
our
elusive goal of providing persistence for POJOs without a framework-
mandated
superclass.
Maybe I'm just old fashioned, but I actually like inheriting behavior.
I also like being able to step through the code to see what it does.
mrg
