spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

obj.GetType().GetProperties(). Durchloopen, Namen + Eigenschaft auslesen und speichern.

Was allerdings hinsichtlich Vorwärts- und Rückwärtskompatibilität keine sehr gute Idee ist. Eine minimale Änderung an irgendeiner Klasse und keine einzige Datei lässt sich mehr laden.

Der Threadtitel sagt aus, die Frage wäre bereits beantwortet. Darf ich fragen, wie das Problem gelöst wurde?

Vielleicht auch nur für nächstes Mal, allerdings hängt es von den Anforderungen ab, was "die beste" Möglichkeit zur Lösung des Problems darstellt. Warum sind die Typen, deren Werte gespeichert werden müssen, nicht bekannt, warum sind diese nicht bekannt und gibt es denn nichtmal eine gemeinsame Ausgangsbasis (gemeinsame Basisklasse oder gemeinsame Schnittstelle)?
Sollte damit bspw. ein Pluginsystem umgesetzt werden, könnte man darüber nachdenken, ob die Schnittstelle nicht bereits Methoden für das Speichern und Laden von Daten beinhalten sollte. Entweder bekommt das Plugin die Möglichkeit, sich gänzlich selbstständig darum zu kümmern (inklusive Dateizugriffe etc.), oder die Schnittstelle definiert Methoden, die vom Plugin eine Serialisierung (Rückgabe als String oder Byte-Array oder ...) oder Deserialisierung (Übergabe vorher gespeicherter Daten) abverlangen, damit das eigentliche Programm sich um die Speicherung kümmern kann (ob im lokalen Dateisystem, in einer Datenbank oder evtl. mit Cloud-Synchonisation).
Es kann sein, dass das in deinem Fall eine bessere Lösung wäre, es kann aber auch nicht der Fall sein.

Der bessere Fall wäre hier eindeutig eine Serialisierung für die erforderlichen Typen einzufordern über ein entsprechendes Interface statt wild irgendwelche Member zu iterieren und in Streams zu schreiben.

Abgesehen davon würde ich dynamic als unsauber und schwer wartbar bezeichnen.
Definitiv ist es in der Benutzung arschlahm und für Reflection braucht man es nicht.
(Ja, das ist eine Funktionalität die ich aus C# rausschmeißen würde, wenn ich könnte)

Zitat von »Legend«

Abgesehen davon würde ich dynamic als unsauber und schwer wartbar bezeichnen.
Definitiv ist es in der Benutzung arschlahm und für Reflection braucht man es nicht.
(Ja, das ist eine Funktionalität die ich aus C# rausschmeißen würde, wenn ich könnte)

Dynamic hat aber schon seine Berechtigung. Erstens wird es für das Einbinden von IronPython etc. benötigt und zweitens kann man einige Dinge eleganter lösen, wie z.B. das Visitor-Pattern. Man muss natürlich wissen, wie und wo man es verwendet, in einem performance-kritischen Algorithmus sicherlich nicht.

Zitat von »BlueCobold«

Was allerdings hinsichtlich Vorwärts- und Rückwärtskompatibilität keine sehr gute Idee ist. Eine minimale Änderung an irgendeiner Klasse und keine einzige Datei lässt sich mehr laden.

Auch hier kann das selbe Problem, wie von dir bereits genannt, auftreten, wenn nicht jedes Property für die Serialisierung explizit ausgewählt wird.
Und wenn das ganze mit einem dynamic object realisiert wird, lässt sich die Datei durchaus ohne Fehler und Exceptions laden.

Zitat von »Legend«

Abgesehen davon würde ich dynamic als unsauber und schwer wartbar bezeichnen.
Definitiv ist es in der Benutzung arschlahm und für Reflection braucht man es nicht.
(Ja, das ist eine Funktionalität die ich aus C# rausschmeißen würde, wenn ich könnte)

Richtig angewendet erspart das dynamic Schlüsselwort viel Zeit und Aufwand. JungleProgger hat übrigens mit dem dynamic object direkt ins schwarze getroffen.
Nicht existierende Properties werden zur Laufzeit generiert, fall eine Versionsinkompatibilität auftreten sollte. Aber ich denke du hast für deine Aussage sicherlich triftige Gründe, die ich gerne erfahren möchte.

Zitat von »Toemsel«

Auch hier kann das selbe Problem, wie von dir bereits genannt, auftreten, wenn nicht jedes Property für die Serialisierung explizit ausgewählt wird.

Hä? Wenn jeder Typ ein Interface für die Serialisierung implementiert, ist nur dieser Typ für seine Serialisierung zuständig und niemand sonst. Klar, wenn ich den Code in diesem Typ verbocke, habe ich Pech. Ich *kann* aber kompatibel programmieren. Aufwärts und abwärts! Das kannst Du nicht, wenn Du einfach stur alle Properties durch iterierst.

Zitat von »Toemsel«

Und wenn das ganze mit einem dynamic object realisiert wird, lässt sich die Datei durchaus ohne Fehler und Exceptions laden.

Klar, aber nur, wenn Du Properties niemals änderst, hinzufügst oder entfernst.