Object Serialization

[Walter Mitty]

I found an interesting sentence in a very old book on Java.

Thus, a single call to writeObject() may result in an entire "object graph" being serialized.

That word "graph" deserves some explanation.  I first ran into that word, used this way,  in the Pascal user manual and report, where it says that dynamic variables and the pointer type  permits the representation of graphs in full generality.  In our ordinary usage, you and I use the word "graphs" to refer to the kind of graphics you would make with a good spreadsheet.  Unless you're a mathematician.  Mathematicians use the word "graph" to mean something quite different.

I'm afraid to offer a formal definition of "graph" in the mathematical sense.  I'm either going to write something incomprehensible, or something formally incorrect, or both.  But I will point out that the world wide web is an example of a graph, or more precisely, a digraph.  Every hyperlink is embedded in one of the objects in the web, and contains the URL of a reference object.  That's enough to make a digraph.

Anyways, the sentence above sparked my interest because it gave me a handle, albeit a slender one, on why Java programmers, when first exposed to SQL, say that they feel like they have gone back to assembler.  I'm pretty good with SQL, and I used to be pretty good with assembler.  Trust me, they aren't very similar.

Anyways, I thought that a discussion of object serialization might help some of you keep the saw sharpened, and might help me do something more concrete than just recall glory days.

[The Gorn]

Errrr... it's not that bad: http://en.wikipedia.org/wiki/Graph_%28mathematics%29

Object serialization is an interesting topic because of the meaning and importance that developers place on it.

I have dabbled with it through the years. It promises the developer that you can have a neat, concise, simple way to persist and later reconstruct run-time object relationships and data contents.

There is a widely used technology called Object-relational mapping, ORM: http://en.wikipedia.org/wiki/Object-relational_mapping. This is the practical current application of object serialization. In essence, an ORM library has the ability to perform RDBMS writes and reads of object data and object graphs.

An ORM library basically uses reflection (ability of the code to see its own constructs like class definitions and object relationships) to persist object data.

Criticisms of ORM are that it's a pig - large run time overhead, and complex.

Here's my view: I have found extremely few reasons in the work I have done to implement object serialization or ORM. There are reasons, but generally they come down to small scale needs like saving user preferences to an object store rather than write the code to write and read INI files.

It sounds more useful than it turns out to be in real life. The main problems with it are slowness and lack of optimization.

IE: perhaps you could deploy an ORM enabled database application much faster than you could write a native code application that used a data model of the real world data to be saved and used later. But you will pay for this ease of development every time you use the application with slowness and much larger data saved the RDB, and, you lose all of the DBA discipline that you have developed - the tool does it all for you so you have no opportunity to model the data yourself.

The problem I have with it is that it's fragile in concept. If you don't implement exactly the same object hierarchy in a reader/data consuming application as in the writer/producer, you don't have a way to access the data.

Codeheads love ORM the most. I don't think DBAs "heart" it very much.

The bottom line is that if you want a data-centric application, it is probably very short sighted to base it upon a current C# or C++ vendor's ORM library.

I could be wrong but this is what I have gleaned from online pro/con discussions.