Re: ORM or JDBC?
Arved Sandstrom wrote:
That's my viewpoint, yes. Another reason I'm not too fond of having
EntityManagers scattered all over the business logic is because
Not all over the business logic, but scattered all over the DAL is fine and
desirable.
EntityManager methods throw RuntimeExceptions - lots and lots of
unchecked exceptions. The guys who wrote the JPA specs must be fans of
Bruce Eckel or something. My general thinking is that for most of these
situations it's the persistence layer that knows best what to do,
followed a close second by the immediate calling code...not some
ineffable error handler way up the call stack.
Totally correct.
But this isn't just for 'EntityManager'. Whoever sees the exception lowest
should deal with it. (Flame off, fans! I know that there are a number of
ways to deal with it. Use one of them at the immediate point of the
exception.) Not some ineffable error handler way up the call stack.
So also for this reason I like having the EntityManager methods centralized.
You've indicated you don't mean this to be a monolithic approach, so I agree 100%.
In practise it can be a bit of hard sell to tell people that now that
they've got 300 or 500 entity classes that they can't use them outside a
DAL. So I tend to follow a few other principles:
"Law of Demeter"?
1. Other frameworks like JSF don't get direct access to JPA entities. As
far as I'm concerned the persistence layer in particular can deal with
views (for which JPQL ctor expressions are quite useful) and true POJOs.
2. Do keep actual EntityManager calls as confined to a DAL as possible.
Calling code can communicate its intent with DAO.save/find/delete
methods, and so forth.
Or more simply, especially if people don't fully grok the "DAL" thing: Keep
'EntityManager's confined.
3. Since we can't lock down entities with finals, do the equivalent:
"updatable=false" where possible, read-only queries, read-only classes
(as in EclipseLink @ReadOnly extension), etc.
4. Use your database to the fullest to impose appropriate constraints.
This is somewhat easier for many developers to do. If the JPA coding
isn't up to snuff then good DB constraints can nip defects in the bud
before they get to prod.
Too bad we always have to say "if X part of the code isn't up to snuff".
Too bad the universe doesn't always do what I like.
5. Also, decent ORMS like EclipseLink can dump their units of work.
Doing code reviews that examine these dumps, made just prior to expected
commits, can be instructive.
You reinforce my sense that ORMs didn't really hit the mark until JPA
generally, and I agree that EclipseLink is a first-rate implementation.
....
Lew wrote:
Maybe I just like JPA so much because I grok the mindset and tend to
avoid the kinds of mistakes you describe. I'm far from expert with it,
but I don't come close to the kinds of problems that ORMs are renowned for.
Arved Sandstrom wrote:
I like JPA too...when _I_ can employ it, using a full-fledged JPA 2.0
ORM with plenty of useful (read "necessary") extensions, like
EclipseLink 2.x.
I'm not nearly as fond of it when I come in as a maintenance consultant
and look at a typical dog's breakfast of a "JPA" app. There's nothing
You only find that with JPA?
quite as discouraging as encountering a complex Java EE app that has JSF
backing beans using JPA entities directly, doing EM methods right in the
backing beans, with no thought whatsoever given to caching, absolutely
no locking of any kind, use of lazy loading with no idea of the possible
consequences...well, you get the idea.
I'm not nearly as fond of Java when I come in as a maintenance consultant and
look at a typical dog's breakfast of a Java app.
Too many God-damned poseurs collect paychecks as programmers. I'm happy just
to see them fired, but I'd be happier still if they had to walk a gauntlet of
real programmers on the way out of the door while we all cry, "Fie, dog!" as
they slink away.
And I *hated* ORMs before JPA came along.
Still do - hate the pre-JPA ORMs that is.
I don't hate them, but with JPA 2.0 I see no reason to prefer them. With
JPA 1.0 it was handy to have the native APIs around - I can think of a
number of things (e.g. search-form driven query builder classes) that
didn't have good JPA 1.0 support.
+1
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg