Re: ORM or JDBC?
Alessio Stalla wrote:
Existing Java ORMs (those known to me, at least) fail at mapping complex enough object graphs.
Depends on what you mean by "fail".
Relations are not (only) Collections, as ORMs would like us to believe.
Collections cannot be a) filtered and b) joined without for() loops in Java.
Not true.
Where the use case is common enough you can create custom collections through
judicious use of JPQL or Criteria, much as you would have to use custom JDBC
queries mapping by hand to a collection (!) were you to eschew JPA.
a) parent.getAdultChildren() can only be implemented as removeMinors(parent.getAllChildren()).
b) grandParent.getGrandChildren() can only be implemented
'Ware claims of "can only be implemented", particularly where several
reasonable alternatives exist.
as for(Person p : parent.getAllChildren()) { collect(p.getAllChildren(); }.
The same alternatives exist for this, too.
That's probably fine (even if too verbose and not easily parallelizable) for objects in memory,
Which is precisely why JPA allows for alternatives.
Yes, it's an object model on top, but you can still leverage the data model at
the bottom. JPA does not preclude that.
but it's completely stupid for objects fetched from a database.
Dropping to JQL, criteria, or SQL is not a solution, because it means stepping outside the OO world to return to a relational view of the world.
Well, it actually is a solution. Yes, it forces you to think about the
relationships a little more deeply than the simple cases you referred to, but
then the relationships are deeper, so that's understandable.
JPQL or JQL or whatever the initialism /du jour/ is still object-oriented, in
the sense that its queries are phrased in terms of objects and their
relationshiops, not tables and rows. This, in fact, causes difficulty for
folks who get confused by its superficial similarity to SQL.
I don't know the .NET world well, but I've been told LINQ can solve both these problems
because it represents relations as Queryables (Iterables on steroids) that support .where and .join methods (or equivalents).
Ummm, that's essentially what JPA does. Collections are all 'Iterables'
albeit not on steroids (thank goodness or Java would suffer the rage episodes
and sexual dysfunction).
Now this is not a reason not to use ORMs in Java at all,
but certainly one must be well aware that seamlessly mapping
a rich domain model to an RDBMS is presently impossible.
"Impossible" is such a strong word, and in this case, inapplicable.
I don't know what you mean by "seamless" but I'll settle for "not harder than
doing it the other way". JPA is not harder than doing it the other way for
the cases you cited.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg