Persisting information - Serialization

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have the need to persist data to a configuration database. We want the
format of this data to be XML. There are two approaches that come to mind
that seem to fit the bill. Below are the two approaches I'm referring to.
Note that I do list what I think are the pros and cons of each approach.

1. .NET Serialization.

We could create classes which can participate in .NET serialization. Since
we want the format of the persisted data to be XML we could either use the
SOAP Formatter or write our own formatter which emits XML.

Pros:

* Get serialization of .NET or Framework types as long as those classes are
marked as [Serializable].

Cons:

* No schema backing the types, or at least I'm not in control of the schema.
For instance, I would have no idea what a Hashtable using the SOAP Formatter
would generate.
* More information serialized than needed. We don't need transient state
persisted so we don't need privates serialized.
* Potential of a breaking change to a .NET or Framework type to invalid all
of my data which includes this type.

2. XML Serialization

We could create classes which can serialize via the XmlSerializer. I have
done this in the past and my usual approach is to first define the XML schema
(XSD) and then have the xsd.exe tool generate the class(es). This approach
ensures that the classes generated conform to the schema since the xsd.exe
tool generates the appropriate XML Serialization attributes.

Pros:

* Data is backed by schema which I control.
* I know exactly what the data looks like (which may come in handy if
someone wants to parse this data in java on Unix).
* Only the data we need serialized will be serialized as opposed to all
public and private data members.
* No potential for a breaking change of a .NET or Framework class to bust my
configuration (of course unless the XmlSerializer class has a breaking
change).

Cons:

* I'm not sure about this, but I assume there are a bunch of .NET and/or
Framework classes that would not serialize via the XmlSerializer. This means
that if I make use of those classes and need to serialize data they contain,
I'll have to write auxiliary classes to serialize that information.
 
nickdu said:
We have the need to persist data to a configuration database. We want the
format of this data to be XML. There are two approaches that come to mind
that seem to fit the bill. Below are the two approaches I'm referring to.
Note that I do list what I think are the pros and cons of each approach.

1. .NET Serialization.

Cons:

* More information serialized than needed. We don't need transient state
persisted so we don't need privates serialized.
Click to expand...

If you have are the creator/owner of the classes that will be
serialized, you can implement ISerializable/IDeserializationCallback to
serialize only the most important data of the objects. I have several
custom and rather complex collections that I serialize this way, it
works very well in these cases.
* Potential of a breaking change to a .NET or Framework type to invalid all
of my data which includes this type.
Click to expand...

I hope they put some kind of version number into what the
BinaryFormatter spits out to keep newer versions backwards compatible. I
haven't yet looked more closely at the data format though.

Max
 
Back
Top