Laden...

Programmdaten speichern, wo & wie? serialisieren?

Erstellt von PoWl vor 9 Jahren Letzter Beitrag vor 9 Jahren 2.413 Views
P
PoWl Themenstarter:in
219 Beiträge seit 2008
vor 9 Jahren
Programmdaten speichern, wo & wie? serialisieren?

Hi,

sicher gabs das Thema schon öfters aber so die gewünschte Antwort hab ich jetzt nicht gefunden.

Es geht darum, dass ich in diversen Tools, die ich mir selber schreibe, gerne Daten abspeichern und beim nächsten Aufruf wieder zur Verfügung hätte. Das können unterschiedlichste Datentypen/Objekte sein. Klar, das erste was einem dazu einfällt ist Serialisierung. Aber da gehen die Fragen los.

Wie strukturiere ich diese Daten?
Schreib ich mir einfach eine Lade- und eine Speichermethode in denen die entsprechenden Variablen dann alle zusammengesammelt und serialisiert/deserialisiert werden? Find ich nicht sehr geschickt denn jedes mal wenn neue zu speichernde Variablen hinzukommen muss ich beide Methoden anpassen.
Schreibe ich mir eine Struktur oder eine Klasse, die als Container für sämtliche zu speichernde Variablen dient? Dann muss ich sie nur noch ein mal instanziieren und dann das Objekt serialisieren und muss die Lade- und Speichermethode nicht jedes mal anpassen. Bei einer Klasse kann ich im Konstruktor sogar noch eine Initialisierung vornehmen, sollte das Objekt nicht deserialisiert werden können und neu erstellt werden müssen (z.B. beim ersten Programmstart).
Hat aber die Unschönheit an sich, dass ich alle zu speichernden Daten nur über den Objektnamen ansprechen kann.

Oder ist Serialisierung in eine Datei doch nicht das Optimum?

Wo sollte die Datei, in die man serialisiert überhaupt abgespeichert werden?
Ich hab mir jetzt mal Environment.SpecialFolder.LocalApplicationData ausgesucht.

Wie macht das der Profi?

T
415 Beiträge seit 2007
vor 9 Jahren

Kommt natürlich drauf an, was das für Datentypen sind. Für einfache Datentypen und Settings in deinem Programm bietet sich das [Tutorial] Konfigurationsmodell im .NET Framework an. Sind es komplexere Sachen, z.B. der Inhalt von Grids o.ä. kannst du auch darüber nachdenken die Daten in einer Datenbank abzulegen (z.B. SQLite).

16.806 Beiträge seit 2008
vor 9 Jahren

AppData ist "schon" der richtige Ordner für Anwendungseinstellungen. Es muss aber zwischen generellen System- und individuellen Benutzereinstellungen unterschieden werden.
Von Haus aus wird ersteres in ProgramData abgelegt, für zweiteres in den AppData des Userprofils.

Ich bin aber auch ein Freund von selbst definierten Speicherorten.
AppData ist prima für Firmenumgebungen, weil überall im Firmennetz die Profile synchronisiert werden. Zuhause hab ich das aber nicht, und dann funktioniert das nicht.
Bei meinen Mini-Anwendungen für mich, wenn ich aus Versehen mal eine Desktop-Anwendung erstelle, übernehme ich die Konfiguration und dessen Serialisierung selbst.

Das heisst, dass in meinen Profildaten (AppData) des .NET Konfigurationsframeworks nur steht, wo die Einstellungen wirklich sind (Pfad) - und das ist dann meist meine Dropbox/OneDrive.
Beim ersten Start definier ich dann also als normaler User nur wo meine Einstellungen gespeichert / geladen werden sollen - fertig.

Ich könnte wetten, dass .NET das Speichern in die Cloud (OneDrive) über das Framework bald selbst abdeckt. Nicht heute, nicht in 2 Monaten (oder doch, mit Windows 9?). Aber "bald".

2.078 Beiträge seit 2012
vor 9 Jahren

Je nachdem, welche Daten zu speichern willst, gibt es verschiedene Möglichkeiten.

Es gibt das Konfigurationsmodell von .NET, was ja schon genannt wurde.
XML bietet sich gerne an, binäre Serialisierung, ein komplett eigenes Format, etc.

Wenn die Daten nicht zu komplex sind und nicht in großen Mengen auftreten, dann nehme ich gerne XML. Wenn der Nutzer die Daten in der Datei selber überarbeiten können soll, dann bietet sich JSON an, oder du überlegst dir etwas, das auf die Daten abgestimmt ist.
Wenn es umfangreiche und/oder komplexe Daten sind, würde ich eher zu einer Datenbank tendieren. Entweder gleich ein Datenbankserver, oder eine lokale Datenbankdatei als Dateiformat. Oder Beides, eine umfangreiche Daten mit den vom Nutzer produzierten Daten und eine Datenbankdatei mit Einstellungen, etc. Die Einstellungs-Datendatei kann der Nutzer dann z.B. einfach kopieren und hat auf einem anderen Rechner ein gleich konfiguriertes Programm.

Wo du die Daten abspeichern willst, musst du dir auch überlegen.
Ich mag ja den Gedanken, dass der Nutzer das selber angeben kann, dazu bietet sich die config an. Das legt man einmal fest und vergisst es danach. Oder du baust einen Part im Programm ein, der das grafisch manipulieren lässt, dann aber Admin-Rechte fordern muss.
Was auch gerne passt, ist der Benutzer-Ordner. iTunes speichert unter Musik, Visual Studio in den Dokumenten, Acrobat Pro auch.
AppData benutze ich nur, wenn es sich häufig ändernde Daten sind, die für den Nutzer nur soweit interessant sind, dass das Programm optimal läuft. So kann man da z.B. das zuletzt geöffnete Dokument markieren, sodass der Nutzer bei einem erneuten Start direkt dort weiter machen kann, wo er aufgehört hat. Diese Daten schaut sich der Nutzer nicht an, müssen aber ständig aktualisiert werden.

Zusammengefasst kann man sagen:
Es gibt keinen optimalen Ort zum Speichern von Daten und auch keine optimale Art.
Es ist aber von Vorteil, wenn du die Vor- und Nachteile der Orte und Arten kennst, damit du je nach Anwendungsfall entscheiden kannst, was die beste Option ist.
Überlege dir also, was das für Daten sind, wie oft sie sich ändern, für wen sie wie interessant sind und wer was damit machen muss.