Hallo,
ich möchte beim Deserializieren eines Objektes den Pfad der Quelldatei als readonly Property mit im Objekt speichern. Da ja beim XML-Deserialisieren der parameterlose Konstruktor verwendet wird, weiß ich nicht so recht, wie ich das anstellen soll. Gibt es da einen offiziellen Weg? Eine Write-Only-Once-Property mit Flag und Exception finde ich nicht so glücklich.
Grüße, Alex
Final no hay nada más
Hallo ill_son,
beim Deserializieren eines Objektes den Pfad der Quelldatei als readonly Property mit im Objekt speichern
Was machst du wenn beim Deserialisieren kein FileStream verwendet wird, sondern ein anderer Subtyp von Stream?
Wenn schon, so würde ich das Objekt wie folgt aufbauen:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
public class MetaPerson : Person
{
public string XmlFileName { get; }
}
Also mit "Meta"-Klasse, so dass das eigentlich (Daten-) Objekt davon unberührt bleibt.
Gibt es da einen offiziellen Weg? IXmlSerializable implementieren, aber das ist ziemlich aufwändig.
Einen eigenen Xml-Serialisierer durch Erben von XmlSerializer
erstellen und die nötigen Methoden überschreiben. Ist u.U. einfacher als IXmlSerializable
zu implementieren.
Den DataContractSerializer
verwenden und OnDeserialized auf eine Methode der Klasse klatschen. Das hat jedoch den Nachteil, dass du in der Klasse eine Abhängigkeit zum Serialisieren aufbaust -- genauso wie bei der Möglichkeit bei IXmlSerializable
.
Wenn das Objekt stets vom gleichen Typ ist, so wäre auch Linq2Xml eine Möglichkeit, spricht manuelle Deserialisierung.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Hallo gfoidl,
vielen Dank für deine Antwort. Zur Thematik FileStream. Es ist sichergestellt, dass das Ojekt immer aus einer Datei serialisiert wird. Hintergrund des Ganzen ist folgender:
Es existiert ein Hauptordner in dem sich mehrere (viele) Unterordner befinden. In jedem dieser Ordner liegt eine zu deserialisierende Datei. Wenn ich in der Anwendung dem deserialisiertem Objekt zugehörige Daten erzeuge (Messwerte, Dokumente usw.), dann sollen die auch in dem entsprechenden Unterordner landen. Deshalb möchte ich den Quellordner (momentan als FileInfo) im Objekt haben.
Grüße, Alex
Final no hay nada más
Hi ill_son,
hier geht es meiner Meinung nach um Separation of Concerns. Es ist nicht die Aufgabe eines jeden Datenmodells zu wissen, wo es herkommt. Genausowenig, wie ein Objekt aus einer Datenbank wissen muß, aus welcher Datenbank es kommt. Oder ein JSON-Objekt, von welchem Webservice es ausgeliefert wurde.
Wenn du diese Info in deiner Anwendung benötigst, dann mußt du sie an einem geeigneten Ort speichern. Dazu benötigst du ein dafür geeignetes Datenmodell. In VisualStudio weiß z.B. auch nicht jede Klasse, in welcher Datei und in welchem Ordner sie liegt. Dafür gibt es dann ein übergeordnetes Objekt, nämlich das Projekt, wo alle Pfade gespeichert sind. So ähnlich solltest du das Problem auch angehen. Deine derzeitige Herangehensweise wird dir früher oder später nur mehr Probleme verursachen, als sie momentan löst.
Weeks of programming can save you hours of planning
@MrSparkle, wenn die Messdaten nur zusammen mit ihrer Herkunft richtig interpretiert werden können, dann gehört diese Info auch zu ihnen. Betonung auf "wenn".
In dem Fall ein Interface IHasSourceInfo, die Datenmodelle davon ableiten und mit einem modifizierten XmlSerializer den Wert einmalig befüllen. Sollte keine große Sache sein.
Wenn du die Info dagegen für die Interpretation der Daten nicht benötigst, sondern zu anderen Zwecken brauchst, ist MrSparkles Ansatz korrekter. Dafür ein geeignetes Datenmodell einführen und gut.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Hallo Sparkle,
auch wenn das etwas philosphisch klingt, aber es kommt darauf an wie man's betrachtet. Im Prinzip ist es egal woher das Objekt deserialisiert wurde. Aber ich muss wissen, wohin mit den erzeugten Daten und deren Speicherort ist der Ordner der xml-Datei. Ich weiß gerade nicht, wie ich das anders lösen soll.
Final no hay nada más