SettingsManager - Einstellungen speichern

Hallo,

ich möchte euch gerne mein Projekt vorstellen: SettingsManager

Es handelt sich dabei um eine DLL zum einfachen Speichern von Einstellungsdaten. Hier die Beschreibung von meiner GoogleCode Seite:
Die SettingsManager Programmbibliothek ermöglicht das einfache Speichern und Laden von Einstellungen oder Konfigurationen. Die Einstellungsdateien können an einem beliebigen Ort gespeichert werden und beliebig viele Einstellungen enthalten. Zusätzlich kann für jede Einstellung ein Standardwert angegeben werden, so dass einzelne oder alle Einstellungen zurückgesetzt werden können. Alle in einer Einstellungsdatei enthaltenen Einstellungen können aufgelistet werden. Einzelne Einstellungen lassen sich jederzeit hinzufügen oder entfernen.

Falls ihr Interesse habt könnt ihr euch die DLL ja mal runterladen. Auf der GoogleCode Seite gibt es auch eine Wiki mit kurzer Dokumentation zu den Funktionen.

Direkter Download: Klick
Weitere Infos: Klick

Freue mich über Rückmeldung!

LG Karim

Bevor Du weiter machst, du kennst [Tutorial] Das neue Konfigurationsmodell im .NET Framework 2.0 ?

Ja, kenne ich.

Es gibt einen Grund warum ich dieses jedoch genau nicht verwenden möchte: Ich möchte den Speicherort und Namen der Einstellungsdatei selbst wählen.

Wieso sollte es einen Entwickler kümmern, wo genau die Konfig-Datei der Anwendung gespeichert wird? Das ist doch ein Implementierungsdetail, um das ich mich als Programmierer gar nicht kümmern müssen möchte. Wenn ich die .NET-eigenen Konfig-Möglichkeiten nutze, sorgt die Runtime (nehme ich an) dafür, dass die Datei an einem gültigen Ort abgelegt ist, auf den der Benutzer auch Zugriff hat. Da muss ich nichtmal mit Schreibrechten rumplagen...

Kannst du mir da ein sinnvolles Einsatzszenario nennen? 😃

Der Ort der Datei ist zum Beispiel dann wichtig wenn das Programm die Datei z.B. exportieren soll. Ausserdem können so einfach zwei Programme auf die gleiche Einstellungsdatei zurückgreifen. Desweiteren kann die Datei auch für andere Zwecke als dem speichern von Einstellungen dienen, zum Beispiel könnten darin Spielstände oder Highscores etc. gespeichert werden.

Also prinzipiell finde ich die Idee gut (verwende schon seit langer Zeit eine eigene Logik um die Einstellungen zu verwalten).

Allerdings hat Deine Lösung einen entscheidenden Nachteil. Das ganze erlaubt keinen streng typisierten Zugriff auf die Einstellungen. Ich arbeite daher mit einer serialisierbaren Klasse, die für jede Einstellung ein Property enthält. Ein Objekt dieser Klasse lade und deserialisiere ich dann beim Programmstart und beim beenden wird das Objekt wieder serialsiert in der Einstellungsdatei abgelegt.

Zu den 'Warum' und 'Wozu' -Fragen der bisherigen Poster:
Das .NET eigene Konfigurationsmanagement hat ein paar Einschränkungen, die nur mit relativ hohem Aufwand zu umschiffen sind. Bsp.:

Settings werden versionsbezogen gespeichert. Gibt es eine neue Version der Anwendung, stehen die Einstellungen der alten Version nicht mehr ohne weiteres zur Verfügung.

In MultiUser-Umgebungen, bei denen die Anwendung nicht lokal installiert ist, ist eine einheitliche und flexible Verwaltung und Ablage der Anwendungseinstellungen nicht ohne weiteres realisierbar.

Um nur mal zwei Punkte zu nennen...

Gruß,

wcseller

Desweiteren kann die Datei auch für andere Zwecke als dem speichern von Einstellungen dienen, zum Beispiel könnten darin Spielstände oder Highscores etc. gespeichert werden.

Dem Argument halte ich einfach mal das Single-Responsibility-Prinzip entgegen. 🙂

Settings werden versionsbezogen gespeichert. Gibt es eine neue Version der Anwendung, stehen die Einstellungen der alten Version nicht mehr ohne weiteres zur Verfügung.

Also für mich ist der Aufruf von Settings.Upgrade() und ein setzen einer zusätzlichen Property Upgraded kein nennenswerter Aufwand... 😉

Desweiteren kann die Datei auch für andere Zwecke als dem speichern von Einstellungen dienen, zum Beispiel könnten darin Spielstände oder Highscores etc. gespeichert werden.
Dem Argument halte ich einfach mal das
> entgegen. 🙂

Warum sollte das gegen Single-Responsibility verstoßen? Was unterscheidet diese Einstellungen von anderen?

Settings werden versionsbezogen gespeichert. Gibt es eine neue Version der Anwendung, stehen die Einstellungen der alten Version nicht mehr ohne weiteres zur Verfügung.
Also für mich ist der Aufruf von Settings.Upgrade() und ein setzen einer zusätzlichen Property Upgraded kein nennenswerter Aufwand... 😉

Kann man sicher so machen, muss man aber nicht. Die Verwaltung der Einstellungen (User- wie auch Application-Settings) in einem eigenen System kann viele Vorteile bringen (z.B. umschalten zwischen versch. Settings ja nach Rolle des Users, mehrstufige Settings-Szenarien (Global, Arbeitsgruppe, User etc.) uvm.). Das bekommst Du mit den .NET eigenen Methoden nur schwerlich hin (ich sag ja nicht, dass es nicht geht)...

Gruß,

wcseller

Hallo zusammen,

dass man das Rad nicht ohne Not neu erfinden sollte, sollte jedem klar sein. Anderseits kann es natürlich immer sein, dass der Standard-Mechanismus bestimmte spezielle Anforderung nicht oder nicht vollständig unterstützt. Diese beiden Tatsachen nochmal ins Bewusstsein zu rufen, ist in Ordnung. Ausdiskutieren sollten wir das in einem Projekte-Thread aber bitte nicht.

herbivore