Laden...

Xml-Deserialize, xml-Pfad readonly in Klasse speichern

Erstellt von ill_son vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.375 Views
I
ill_son Themenstarter:in
227 Beiträge seit 2009
vor 5 Jahren
Xml-Deserialize, xml-Pfad readonly in Klasse speichern

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

6.911 Beiträge seit 2009
vor 5 Jahren

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!"

I
ill_son Themenstarter:in
227 Beiträge seit 2009
vor 5 Jahren

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

5.658 Beiträge seit 2006
vor 5 Jahren

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

3.003 Beiträge seit 2006
vor 5 Jahren

@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)

I
ill_son Themenstarter:in
227 Beiträge seit 2009
vor 5 Jahren

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