Re: Restoring Swing applications after minimising

Lew wrote:


Arne Vajh?j wrote:


I don't know about CODASYL specifically, but I get your point. There are
significant similarities at the data layer between network databases, and I've
worked with several other than CODASYL, in particular both allocate relations
as part of the data layer. They obtain significant query speed and modeling
strength in the case where the object model always maps to the data model
including the relationships. They lack somewhat in flexibility, having
trouble expressing novel relations without coupled changes to the object model
and vice versa. The relational model gains in flexibility and the "cheat" of
indexes offsets most if not all the performance disadvantage for well-known
relationships.

OODBMSs seek to leverage the strength of direct object model expression in the
data layer. There is strength, IMO to the degree that they give the
developers an object view into the data. This in turn helps move the logic
programmer away from a data-centric programming mindset and toward better
modeling. Good things.

Object-relational mapping frameworks, ORMs, are the attempt to put camel's
feet on a bicycle so you can ride in the desert. Ahem, so to speak.

It turns out that you don't even need a data layer to think about your program
in terms of an object model. You could just formulate a good object model and
cast it in terms of Entity instances and operations thereupon. From that
point of view you simply wave a magic wand and your information lasts forever.

It also turns out that for the greater part of workaday projects, you can do a
naive translation of entities to tables and get a good data model match, even
with a relational database. Just ignoring relations in the code for a
minute, mind you. But early on, you do get a sense of foreign key relations
and you model some simple parent-to-child relationships and many-to-many
liaisons with a straightforward matching of foreign keys to Java collections.

Now here's the beautiful part: both OODBMSes and JPA apps on top of regular
ol' SQL table-based ones turn the programmer loose in that world of object
modeling only, and both hide all the messy data-level crud from application
development. With just a sensible understanding of simple normalization and
foreign key references, you can do what little tweaking of the data model you
really need, which isn't usually much coming from either JPA or an OODBMS.

At that point, the assessment of the two approaches has to diverge. I
conclude that the JPA+RDBMS combination is the best of both worlds - domain
logic from the object model perspective and data from the data perspective.

--
Lew