Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

Kurzabriss: Serialisierung in .NET

Nächster Beitrag (morgen...) : Warum man in XPLA den Zoom-Ausschnitt nicht mit Scrollbars verschieben kann (und wie das beim Faltwerk ist.)

Serialisierung in .NET - bzw: Eben keine

Meiner Ansicht nach nicht besonders gelungen in .NET: Serialisierung von Objekten auf die Platte, mit anderen Worten: Das speichern von Eingabedaten.

Für persistieren gibts drei Klassen in .NET: Den XmlSerializer, den SoapFormatter und den BinaryFormatter. Soap- und BinaryFormatter unterscheiden sich im wesentlichen dadurch, das der SoapFormatter ein von Menschen lesbares (naja, was man im Fall von Soap so lesbar nennt) Format erzeugt, während der BinaryFormatter eben eine Binärdatei anlegt. Die beiden sind ansonstem im Wesentlichen gleich.

Der XmlSerializer ist primär dafür gedacht, stark typisierte Daten als typisierte XML-Files abzubilden. Ergebnis: typische beliebige Objektgraphen sind damit nicht speicherbar. Einer der Gründe ist unter anderem der, das der Formatter alle Typen kennen will die er speichern soll. Das gilt auch für abgeleitete Klassen. Nachdem der Sinn des Ableitens unter anderem in einer späteren Erweiterung einer Klasse besteht, kann man den XmlSerializer also de Facto dafür nicht benutzen. Anders ausgedrückt: Damit kann man nur dann Daten persistieren, wenn man vorher weiss, wie sämtliche zu persistierenden Objekte aussehen, und in welchen Klassen die vorliegen. Das mag bei Datenbank-Daten gehen, bei Anwendungen die durch neue Objekte erweiter werden können geht das schlicht und ergreifen nicht. Bei Daten bei denen es geht, ist das XmlSerializer dafür sehr schnell.

Anders als die *Formatter. :-(

Die können zwar beliebige Graphen persistieren, sind dafür aber lahm. Und obendrein noch geschwätzig, denn die sind eigentlich für den Transport von Daten übers Netz (also z.b. für die Webservice Kommunikation). Darum enthalten dann die Dateien die man damit erzeugt auch massive Menge an Soap-Markup, das fürs 'ganz normale' speichern von Eingabedaten einfach nur sinnloses Overhead bedeutet.

Gelernt: XmlSerializer ist prima für Daten die von Menschen lesbar sein sollen, sofern alle beteiligten Typen vorher bekannt sind. (Also zum Beispiels fürs persistieren einer Menüstruktur.) *Formatter ist eigentlich was für WebServices. Zum Speichern von lokalen Daten gibts nichts spezialisiertes.

Traurige Sache, man sollte eigentlich erwarten das sowas elementares mitlerweile Teil der Infrastruktur ist. Ist es aber eben nicht.

Comments are closed