[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 whole
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 system
under design.
I would consider ORM useful if it helps me to "map" one to another to create
an application that meets some set of requirements. To be precise "mapping"
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 - classes
implementing neural network computations. There is no single class related
to accounting in the library C. The only connection between accounting and
neural networks is the application under design - it provides the necessary
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 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_ 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 create
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.
There is even more "insanity" - once we have class model B - we start using
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).
[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 project.
As soon as I get an ORM tool capable of mapping to _arbitrary_ class model I
am going to use it wholeheartedly. Until that happens I think I would just
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.
