Re: ORM or JDBC?
Arved Sandstrom wrote:
I'm in agreement with this latter thinking, period. I now believe that
objects that figure in the presentation layer should have no meaning or
"liveness" to another frameworks.
By presentation layer I mean specifically that, I don't mean web-tier.
You can have a valid, well-thought-out app that is 100 percent bundled
into a WAR and the entire thing is in the web tier...but it still has
(or should have) distinct layers.
To return to my first statement, if we assume that the presentation
layer is JSF, and another framework is JPA (for the persistence layer),
I am no longer happy with JPA entities being in JSF backing beans,
figuring in JSF getters and setters. If at all possible I'd minimize
(read "eliminate") the use of JPA in all JSF managed beans.
Contrary to many articles, blogs and much evangelism, JPA entities are
not POJOs, never have been POJOs, and never will be POJOs. Expose them
to JSF, say, and sooner or later you'll get an unplanned UPDATE to the
database. And are the developers writing the presentation code all JPA
gurus who know to carefully maintain code-side consistency of JPA entity
relationships? It's not like a JPA provider will do that for you.
I'm gradually leaning towards an even stronger interpretation, which is
that JPA entities shouldn't even leak out of the _persistence_ layer.
I've seen too many problems happen when developers who are not immersed
in JPA ORMs, which is most developers, use entities in the business
logic. Considerably better, IMHO, to confine JPA entirely to a DAL.
A lot of what I say above seems to defeat some of the purposes of JPA,
and I concede that. It's why I am increasingly unconvinced that JPA is a
good fit for the majority of applications. Or more to the point, I'm
increasingly unconvinced that JPA is a good fit for applications + teams
that are not JPA experts.
I agree with your observations insofar as JPA entities (at least while
managed) need to stay in the JPA layer (which need not be monolithic, nor
should it be).
I also enthusiastically agree with your comments about separation of concerns
generally, and about the need for those programmers who work with JPA *to buy
a frakking clue* about how to use it.
You don't have to be an "expert" in JPA to use it correctly. The problem is
that too many people working with JPA aren't even MINIMALLY competent with it,
argue with you if you are competent with it based on their ignorance, and have
the support of management to use it wrong.
There is a right way to use JPA where it works even in the scenarios that have
disappointed you. Having incompetent programmers on the team isn't it.
Honi soit qui mal y pense.