Re: Looking for a lightweight persistance framwork
On Sun, 17 May 2009, charlesbos73 wrote:
On May 16, 6:37 pm, Roger <roger.var...@googlemail.com> wrote:
I'm about to start a small web project that's going to need a small
database comprising about half a dozen master data tables and two or
three transactional tables. The size of the project doesn't warrant a
full blown persistance framework like iBatis or Hibernate, and I really
can't be arsed to roll my own. So what would people recommend?
If the solution to your problem is really better expressed using a
relational DB *and* if you really need to use Java then you have to deal
with the "Object-Relational impedance mismatch". In that case you'd be
better to reuse one of the tested and proven ORM out there, as others
pointed out.
However, seen that it is a small web project and seen that you happen to
be posting in a newsgroup that talks about a language that can be used
in a OO way, it may be a good opportunity to discover how simple and
elegant an OODB can be.
Note that this shall come as heresy in a newsgroup where procedural
advice on one hand, and RDB advice on the other, are given daily as it
was perfectly normal.
Some people like the XML + ORM flagellation coupled with 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 !? ;)
Other consider this kind of development to be everything that is wrong
with Java.
Others should probably calm down a bit. I'm aware that there's a been a
long, smouldering holy war around the subject of object DBs, but the fact
is that modern ORMs, working through JPA, are just as easy to use as
OODBs, if not more so.
Where ORMs win over OODBs is that because their data lives in an RDBMS,
it's accessible other than via the software layer - because the app i work
on ultimately stores its data in an Oracle database, i can dump it,
inspect it, modify with it, etc, with great ease. OODBs, on the other
hand, are black boxes - the only way to get at the data is through the
OODB, and sadly, there isn't the level of standardisation and tool support
around those as there is around RDBMSs.
I'm not saying that ORMs rule and OODBs drool, but that both are perfectly
workable. As would be, in this case, JAXB or plain old serialisation.
Ted Neward calls this kind of development the "Vietnam war of software
development". Englightening read.
You mean this, i take it:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
This seems to me to be an extremely long article which says nothing of
value: it throws out a lot of indisputable but irrelevant facts, suggests
a nonsensical allegory, and then draws an entirely unsupported conclusion.
In particular, it's striking that he spends a lot of time bashing ORMs for
things that OODBs are just as bad at - can an OODB handle his 'acceptable
spouse' query in less than O(n) time?
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".
Mindboggling.
The only thing that's really mindboggling here is your ranting prejudice
against ORM, and your contempt for other programmers.
tom
--
Basically, at any given time, most people in the world are wasting time.