Re: ORM or JDBC?
On 03/24/2011 09:16 AM, Michal Kleczek wrote:
Arved Sandstrom wrote:
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.
But JDBC is a pretty damn good generic DAL by itself so creating a separate
DAL using JPA on top of it is just waste of time and money.
That's not what JPA is, and it's not a waste of time or money.
ORM makes sense when there _exists_ an object model that _implements_
business logic (so JPA entities would not be _used_ by a "business logic
layer" but rather _are_ business logic if you can say it that way).
And by "business logic" I mean logic that is _specific_ to the purpose of
the application. So if the application is about presenting/manipulating data
using GUI - it would be a GUI library of choice.
No.
ORM makes sense when you want to abstract away the mechanism to fill your
objects with data from the persistent store, and the mechanism to persist data
to the datastore from those objects.
It saves time and money by reducing the code involved with data access and
confining it to the appropriate layer, and expressing the mapping declaratively.
The problem with existing ORM tools (and JPA is no different) is that they
are not capable of mapping arbitrary object models to arbitrary data models
for example:
Wrong.
map a general ledger database to a Swing GUI object model
That's a bullshit example.
What you want to do is map the data from the database to objects that
represent general ledgery things.
ORMS do that very well.
map a billing database to an object model defined by a neural networks or
linear programming library
I'm sure JPA would work just fine if I understood what you meant by that exactly.
I'm sure, because JPA will allow you to conveniently map the data behind that
billing system (it's not a "billing database" unless it's backing a billing
system - the logic defines the system, not the data) to any object model that
makes sense for that data. Whether that object model supports neural net
operations or not is irrelevant; JPA focuses on the persistence aspects and
has no effect on what you do with the objects once you've gotten away from the
persistence actions.
You are factually incorrect in your assertions that JPA cannot handle those
use cases. It can handle them with no more effort than a straight JDBC
approach, and in my experience, far, far less. But even if the effort were
greater, your statement "they are not capable of mapping arbitrary object
models to arbitrary data models" is counter-factual.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg