| 

.NET C# Java Javascript Exception

10
Hallo zusammen,

ich bin gerade über folgendes Problem gestolpert ...

Ein Objekt meiner Klasse liegt binär serialisiert vor. Bisher sah der Quellcode für eine Property in der Klasse so aus, angelegt als "propfull":

protected int m_Foo;

public int Foo
{
get
{
return m_Foo;
}
protected set
{
m_Foo = value;
}
}


Da ich derzeit aber keinen besonderen Code im getter/setter - Teil benötige habe ich den Code auf die "Kurzschreibweise" umgestellt:

public int Foo { get; protected set; }


Mit dem Resultat, dass ich die Objekte zwar immer noch deserialiseren kann, aber die Eigenschaft "Foo" nicht mehr den gespeichert Wert beinhaltet, sondern nur "0" ist.

Jetzt kann man natürlich sagen: "Ja klar, m_Foo existiert ja auch nicht mehr und intern wird eine andere Variable zum Speichern verwendet."

Aber das bedeutet jetzt eigentlich für mich, dass ich in Klassen die jemals serialisiert werden, auf keinen Fall die Kurzschreibweise für eine Property verwenden darf! Ich kann nachträglich nie mehr auf die andere Schreibweise umstellen, falls ich mal Code im getter/setter - Teil benötige?

Wie ist da Eure Erfahrung? Gibt es "Best Practice"?

Ich bin kurz davor die Kurzschreibweise "per Coding Standard" komplett zu verbieten und alles auf die ausführliche Schreibweise umzustellen.

Danke,
Mike
08.02.2012
Xantiva 2,3k 2 9
Xantiva 2,3k 2 9
1 Antwort
1
Hallo,

ich hab's grad ein wenig analysiert. Es wird tatsächlich das Field gespeichert. Im ersten Fall also m_foo und im zweiten Fall in etwa <Foo>k__BackingField
Dir bleibt also höchstens noch, den binary stream anzupassen und die entsprechenden Field-Namen auszutauschen.

Alternativ verwendest Du einen eigenen Formatter, der damit umgehen kann.

Aus dem Grund aber die kurze Schreibweise zu verbieten ist nicht wirklich Dein Ernst, oder? Verbiete doch stattdessen die Anpassung ;) In Deinem Fall musst Du ja sowieso Änderungen verbieten (an den Feldnamen)...

Welche Felder serialisiert werden, kannst Du mit
FormatterServices.GetSerializableMembers

prüfen
08.02.2012
WolfgangKluge 1,0k 2 7
Noch ist das Kind nicht in den Brunnen gefallen, also es noch keine relevanten Daten generiert, die später nicht mehr lesbar wären. Von daher werde ich nun einige Stunden damit verbringen, die Kurzschreibweise "aufzulösen". Zumindest bei den Klassen, die serialisiert werden.
Das (mögliche) Ändern der Feldnamen ist dann nicht ganz so schlimm. Das könnte man zur Not ja wieder rückgängig machen. Mit den internen Feldern wird das etwas schwieriger.
Das ist ein guter Hinweis (FormatterServices.GetSerializableMembers), Danke.
Xantiva 08.02.2012
Noch was. Da der Name des "backing fields" vom Compiler generiert wird, ist es ja grundsätzlich auch möglich, dass sich der Name mit einem neuen Compiler ändert.
Daher die Auto-Properties lieber erst gar nicht serialisieren. (also das Serialisieren verbieten, nicht die Verwendung)
WolfgangKluge 08.02.2012
Aua, stimmt. Man kompliliert neu und nichts geht mehr ... Keine schönen Aussichten.
Eine Vorgabe "NonSerialized für Auto-Properties" ist vielleicht ein Kompromiß. Allerdings befürchte ich, dass das im entscheidenden Augenblick dann vielleicht doch mal vergessen wird.
Xantiva 08.02.2012
2
Das hat mir keine Ruhe gelassen ...
http://community.bartdesmet.net/blogs/bart/archive/2007/03/03/c-3-0-automatic-properties-explained.aspx

2007 wurde das daraus: .field private string '<>k__AutomaticallyGeneratedPropertyField0'
5 Jahre später wird daraus: .field private string '<Name>k__BackingField'

Die Namensänderung durch die Compilergenerationen ist also bereits Realität.
Xantiva 08.02.2012
Noch ein Nachtrag:
Mit dem Wissen, macht auch die "Beschränkung" der optionalen Werte [OptionalField] für die Serialisierung auf die Felder einen Sinn: Für eine Property braucht man das nie, weil die Property sowieso keine Daten hält ...
Xantiva 15.02.2012

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH