Re: ORM or JDBC?
Michal Kleczek wrote:
Now imagine schema S desribes an accounting database and library C - clas=
ses
implementing neural network computations. There is no single class relate=
d
to accounting in the library C. The only connection between accounting an=
d
neural networks is the application under design - it provides the necessa=
ry
context. The question: does it make sense to use ORM to do the "mapping"?
It depends.
If you have entities that are modeled in the database, it makes sense.
Then imagine library C is a GUI widget library. Does it make sense to use
ORM in this case? It would be sooo convinient to be able to write:
void main(String[] args) {
EntityManager em = ...;
JFrame f = em.find(JFrame.class, "main");
f.show();
while(true) {}
}
and use ORM parametrization and "magic" to map S (accounting database
schema) and C (UI classes) to have accounting UI without pain :)
(Yes - I know the above is taking ORM to the extreme - but it is _just_ t=
o
illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas t=
o
_arbitrary_ class models).
If you don't have an ORM map to intermediate entities, then you have
to manually map to those entities.
If you "map" directly from the DB to your widget, you are still
mapping to the entity represented by the widgete. Since you are dead
set against modeling that domain entity as anything other than a set
of related tables or a set of related widgets, you're right, an ORM
will be of no use. But that's not because you are saving any
mapping effort. You've just traded the effort of an entity model for
the sometimes greater effort of maintaining widget-to-table mappings
by hand.
What supporters of JPA say instead is that it is a "good practice" to cre=
ate
another class model B (so called "business model") then use ORM to "map" =
the
database schema to class model B and then write more code to "map" class
model B to class model C. The problem is that there is no application
specific "business logic" I could put into B since all of it is already
implemented in C.
Fine.
There is even more "insanity" - once we have class model B - we start usi=
ng
It is appropriate that you put "insanity" in quotes here, since the
real thing you attempt to disparage is not actually insane.
data binding library based on reflection (Java Beans conventions) to move
data from instances of B to instances of C - loosing the last inteded
benefits of having B (namely type safety).
Why would you do that? It's not a JPA thing.
Using JDBC on a per-project basis is designing an ORM tool for one
particular
database schema. That tool is your data-access layer for that project=
..
As soon as I get an ORM tool capable of mapping to _arbitrary_ class mode=
l I
am going to use it wholeheartedly. Until that happens I think I would jus=
t
You mean like JPA, then.
Well, strictly speaking what it maps to is arbitrary *entity* models,
which is far more useful.
It actually is not useful to map to arbitrary class models. Just as
'enum' doesn't handle every type-safe enumeration scenario, JPA is not
even intended to handle *every* data-access scenario.
THERE IS NO LIBRARY THAT WILL DO WHAT YOU ASK, NOR CAN THERE EVER BE.
That's like saying, "Until clean energy gives me a perpetual-motion
machine I will stay with fossil fuels." It's a ridiculous
precondition.
JPA is only intended for the subset of mappings that make sense.
You're asking for one that doesn't make sense, then deriding ORMs for
not supporting it. So don't use an ORM. It's not even meant for
everything.
So, "It doesn't do everything" is a bullshit complaint.
stick to more lightweight tools such as Spring JDBC that resolves some
inconvinience of JDBC (connection/resource management etc.) while still
giving me freedom with designing my class model.
Making JPanel a domain object for an accounting system is an abuse of
freedom. But you go, girl!
--
Lew