Re: Looking for a lightweight persistance framwork
charlesbos73 wrote:
Some people like the XML + ORM flagellation coupled with
Merely calling it "flagellation" doesn't make it bad in reality.
Java used in a purely procedural way (coupled with a
little GOTO-style programming here and there... But nothing
can go wrong when you know fineprint 6.3.2.17b of the JLS
right !? ;)
"Obscuring is distinct from shadowing (?6.3.1) and hiding (?8.3, ?8.4.8.2,
?8.5, ?9.3, ?9.5). The naming conventions of ?6.8 help reduce obscuring"?
There is no subsection 17 of JLS 6.3.2, and the JLS doesn't identify
paragraphs by letter.
Model your solution using OO techniques (once again, this
is probably heresy in this newsgroup)
Considering that Java is an O-O language, it's more than a little peculiar to
think that O-O modeling would be "heresy" in comp.lang.java.programmer.
and use an OODB like db4o.
Or use JPA (the Java Persistence API), which provides a superb impedance match
between the object and relational models.
I'm probably very lucky to work in a domain where OO
shines... Most developers here are so used to do
ORM plumbing in their dayjob that their mind became
hardwired to answer "use a SQL RDB".
Relational databases are good at modeling data, and have real strengths in
that regard. Their main strengths are flexibility when you want to support a
different object model off the same data, and the avoidance of data anomalies.
"Object-oriented" databases, really a rework of the old network-model
database systems, lock in a specific set of relations; relational databases do
not.
There are good reasons why relational databases have essentially taken over
the market from network-model databases, and why in over twenty-five years
so-called "object-oriented" databases have not gained much traction.
From a programming standpoint, JPA POJOs are about as simple as db4o objects
seem to be. As an added advantage, with JPA you don't usually have to
explicitly recognize that you're dealing with a database; you can focus on the
object model while working within the Java perspective. Not to say that you
can't use JPA in a data-model-aware fashion; people all too often do so, and
admittedly occasionally it's useful or necessary to do so. Nevertheless, JPA
is quite successful at keeping the Java perspective object-oriented without
sacrificing the distinct advantages of the relational model from the data
perspective.
JPA software plus relational database also allows one to configure different
object models atop the same back end.
Bottom line: for domain logic, object-oriented rules. For data storage,
relational rules. For that impedance mismatch, JPA rules.
--
Lew