Daniele said:
My emphasis was on "your" -- in the sense of: something the OP ought to
be closely acquainted with. His use of the word "objects" could be
interpreted to mean that the model is already in place. But either way,
you Lew make a very valid point.
As do you, Daniele. As did Arved in another communication.
Despite what I said, I recognize that JPA can, and sometimes should be used as
a way to adopt a database model into an object model, rather than simply persist
the object model. JPA is not intended for overly rococo data models, such as the
kind where every DBA trick in the book is pulled, but within its intended sphere it is
very useful to impose an object model atop a data model.
But that doesn't mean one should program the application the same as if they were
using JDBC. In such a situation, why not use JDBC? The idea is to graft an *object* model
onto the data, or use the datastore to persist the *object* model, not to write Java code for
a relational model. That's the reason for having a mapping at all between object and relational
models, that is, an object-relational mapping (ORM).
JPA is not for writing relational code. That's what JDBC is for.
There's a lot more to JPA than that, of course. In my own experience I've found a very
effective idiom for JPA, but I'm having trouble articulating it. I've even written code comparing
a "classic" monolithic Hibernate approach (a giant Session for everything) vs. a "modern" JPA
approach - tiny data-access helpers each with their own EntityManager, one per service. (Also
used Hibernate for that one.) The tiny-helper approach was much easier to work with and
understand and optimize, IMO. I've been on a few projects where the monolithic ORM session
caused huge problems.
It's the same sort of thing that has Java coders write local object references inside a loop instead
of longer-lived ones declared outside the loop. The short-lived objects release their resources
quicker (e.g., don't move to the tenured generation) and are easier to reason about.
