myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Basistechnologien und allgemeine .NET-Klassen » Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten

 
Beiträge zu diesem Thema Autor Datum
 Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten MichiM 06.04.2004 13:28
 RE: Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten MichiM 07.04.2004 01:02
 RE: Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten herbivore 22.01.2006 09:57

Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
MichiM
myCSharp.de-Mitglied

Dabei seit: 09.02.2004
Beiträge: 14


MichiM ist offline

Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo C#-Freunde,

hat hier jemand eine Ahnung, warum .NET die einzelnen Serialisierungsformate bzgl. der Zugriffsmodifizierer bei den Daten unterschiedlich behandelt?
Na gut, weil die Klassen halt so geschrieben sind, ok. smile Aber hat das einen tieferen Sinn?

Warum werden bei der XML- und SOAP-Serialisierung nur diejenigen Daten serialisiert, die als public deklariert sind? Warum sind dagegen bei der binären Serialisierung die Zugriffsmodifizierer dann wieder egal?

MfG
Michi
06.04.2004 13:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
MichiM
myCSharp.de-Mitglied

Dabei seit: 09.02.2004
Beiträge: 14

Themenstarter Thema begonnen von MichiM

MichiM ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Könnte es vielleicht damit zusammenhängen, dass man XML und SOAP ja eher zur Kommunikation mit anderen Anwendungen verwendet, also von daher auch normalerweise Daten serialisiert haben will, die die anderen was angehen, also nicht private sind, während man bei der binären ja für sich selber serialisiert (z.B. Konfiguration bei Programmende) und da alles serialisiert haben will? Eine andere Erklärung find ich nicht....
07.04.2004 01:02 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Zwischen diesen beiden Beiträgen liegt mehr als ein Jahr.
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.475
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo MichiM,

ich betätige mich mal als Archäologe, weil ich das Thema spannend finde.

Zitat:
Serialization is the process of converting the state of an object into a form that can be persisted or transported.

Die entscheidende Frage ist, was man als Zustand (state) des Objekts ansieht. Je nachdem welche Sicht man dabei einnimmt, kommt man zu unterschiedlichen Ergebnissen.


Aus der Sicht des Benutzers einer Klasse wie beispielsweise Datum mit den Properties Tag, Monat und Jahr, bestimmt der Wert dieser drei Properties den Zustand des Objekts. Was anderes kann man von außen ja auch nicht sehen. Wir könnten das also den äußeren Zustand nennen. Das ist auch der Zustand, den die XML-Serialisierung verwendet, indem sie die Werte der Properties ausliest; leider mit einer wesentlichen und unangenehmen Einschränkung. Und das liegt an der Deserialisierung:

Zitat:
Complement of serialization is deserialization, which converts a stream into an object.

Da beim Auslesen des Zustandes die Properties verwendet werden, müssen sie auch für das Zurückschreiben verwendet werden. Sonst wäre das Ganze halbherzig und asymmetrisch. Deshalb werden schon beim Serialisieren nur die Properties ausgelesen, für die neben einem öffentlichen Getter auch ein solcher Setter existiert.

Damit ist aber - so schön der Gedanke ist, die Kapselung der Objekte nicht zu verletzen und den äußeren Zustand zu verwenden - die XML-Serialisierung in meinen Augen fast immer unbrauchbar. Man denke nur an immutable Objekte wie Color, die sich deshalb (standardmäßig) nicht XML-Serialisieren lassen. Anm.: Die Basistypen wie char, int, String u.ä., die ja auch immutable sind, können nur deshalb standardmäßig xml-serialisiert werden, weil die XmlSerializer-Klasse diese intern extra behandelt.

Weitere Schwierigkeiten gibt es, wenn eine Klasse Properties für verschiedenen Repräsentationen desselben Zustandes zur Verfügung stellt. Wenn beispielsweise die Klasse Punkt (zweidimensionale Koordinaten) nicht nur die Properties X und Y (kartesische Koordinaten) zur Verfügung stellt, sondern auch R und Phi (Polarkoordinaten). Zum einen werden hier Informationen redundant abgefragt, gespeichert und gesetzt, zum anderen kann es zu Rundungsfehlern führen, je nachdem in welcher Reihenfolge die Properties verarbeitet werden.

Man kann sich beliebige weitere Beispiele vorstellen, bei der die Benutzung von Properties Probleme macht, z.B. wenn Prüfungen in denselben fehlschlagen, weil die korrekte Reihenfolge des Setzens durch die (standardmäßige) Deserialisierung nicht eingehalten wird.


Aus der Sicht des Implementierers der Klasse Datum sieht die ganze Sache anderes aus. Für ihn ist der Zustand des Objekts gegeben durch die Felder (Exemplarvariablen) des Objekts. Das könnten z.B. die Anzahl der Sekunden seit dem 01.01.1970 sein, also eine ganz andere Repräsentation als die, die der Benutzer der Klasse sieht.

Kleiner Einschub: In meinen Augen sollten alle Felder private oder protected sein, aber nie public. Will man, dass ein Feld eigentlich auch nach außen zur Verfügung steht, dann stellt man stattdessen eine entsprechende public Property zur Verfügung, lässt das Feld selbst aber private oder protected.

Die Felder kann man also nur von innen sehen. Wir könnten das also den inneren Zustand nennen. Das ist auch der Zustand, den die binäre Serialisierung verwendet, indem sie die Werte der Felder ausliest; da Felder (Variablen) jedoch immer auch schreibbar sind, entstehen hier keine Einschränkungen wie bei der XML-Serialisierung.

Genau genommen, gibt es auch bei Feldern Einschränkungen der Schreibbarkeit, aber diese manchen keine Probleme. Bei readonly Feldern entstehen deshalb keine Einschränkungen, weil die Deserialisierung einen Konstruktor verwendet. Dort sind auch readonly-Felder schreibbar. Und const Felder sind eigentlich gar keine Felder sondern Konstanten, die ohnehin ihren festen Wert haben und weder serialisiert noch deserialisert werden müssen.


Zu guter Letzt kann man sich noch fragen, warum gerade die Xml-Serialisierung den äußeren Zustand und warum die die binäre Serialisierung den inneren Zustand verwendet? Ich denke, das liegt daran, dass eine Xml-Datei auch menschenlesbar ist und damit dem Benutzer der Klasse zugänglich. Um die Kapselung nicht zu verletzen, darf dieser natürlich nur den äußeren Zustand sehen. Das Ergebnis der binären Serialisierung ist jedoch ohne Kenntnis des inneren Aufbau des Objekts ohnehin nicht verständlich. Deshalb kann hier getrost der innere Zustand verwendet werden.

herbivore

Suchhilfe: Auch wenn es nur gut 600 Worte sind spendiere ich mal das Stichwort 1000 Worte.
innerer Zustand, äußerer Zustand
22.01.2006 09:57 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 16 Jahre.
Der letzte Beitrag ist älter als 14 Jahre.
Antwort erstellen


© Copyright 2003-2020 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 13.07.2020 06:13