Re: ORM or JDBC?
On Mar 29, 9:14 am, Silvio <sil...@moc.com> wrote:
On 03/28/2011 04:53 PM, Michal Kleczek wrote:
[snip]
(BE WARNED: below you're going to find controversial ideas described by=
a
lot of people as "bad engineering practices" - but please read the whol=
e
thing before criticizing :) )
Imagine you have two models: a database schema S and a class library C.=
Both
are completely independent and both capture a certain aspect of the sys=
tem
under design.
I would consider ORM useful if it helps me to "map" one to another to c=
reate
an application that meets some set of requirements. To be precise "mapp=
ing"
means moving data from the db to instances of classes from library C
(potentially creating instances of those classes) and back to save the =
state
of those instances in the database.
Now imagine schema S desribes an accounting database and library C - cl=
asses
implementing neural network computations. There is no single class rela=
ted
to accounting in the library C. The only connection between accounting =
and
neural networks is the application under design - it provides the neces=
sary
context. The question: does it make sense to use ORM to do the "mapping=
"?
Then imagine library C is a GUI widget library. Does it make sense to u=
se
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_=
to
illustrate the weaknesses of current ORMs in mapping _arbirary_ schemas=
to
_arbitrary_ class models).
What supporters of JPA say instead is that it is a "good practice" to c=
reate
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" clas=
s
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.
There is even more "insanity" - once we have class model B - we start u=
sing
data binding library based on reflection (Java Beans conventions) to mo=
ve
data from instances of B to instances of C - loosing the last inteded
benefits of having B (namely type safety).
[snip]
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 proje=
ct.
As soon as I get an ORM tool capable of mapping to _arbitrary_ class mo=
del I
am going to use it wholeheartedly. Until that happens I think I would j=
ust
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.
Well, this is more or less my take on the subject. I rarely go to the
trouble of explaining it in this length since, as you said, most people
tend to think we have it all backwards...
I think you're both missing a key point: OR mapping is not done just
for the sake of mapping - to bring data straight from the DB to the
GUI and vice-versa. Were it true, then I'd agree that ORMs do not add
any value.
Instead, ORMs exist because most people find it useful to represent
the domain model as "something" which is neither the DB, nor the GUI.
I'm not advocating OO as The Only True Way, but if one chooses Java
(and thus OO), that's basically the main way. So the objective of the
OO programmer is: let's reason about the domain using a class-based
model. Such a model is "pure", it exists in isolation, it is a library
with no interaction with the outside world - at least, it should be.
The OO domain model is the core of the application. While the GUI is
replaceable, the DB is replaceable, etc. the domain model is not - if
you replace it (with a sufficiently different one), you get a
different application. Then, given that everything gravitates around
the domain model, you need every other piece of the application to
talk to it. For GUIs, this means data binding (and a service layer for
client-side GUIs with a server counterpart). For RDBMSes, this means
ORM. For XML, this means JAXB or other mapping technologies, etc. etc.
If you skip the domain model part, and pretend the GUI is the model of
your application, then you're simply not doing Object-Oriented
Programming. That is not a crime, mind you, but then I don't
understand why you're using Java in the first place.
Alessio