Best Practice - Anwendungsweite Einstellungen?

  • C#

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Joshi.

    Best Practice - Anwendungsweite Einstellungen?

    Hallöchen,

    ich hadere bei jedem neuen Projekt wegen der Einstellungen....
    Diese sollen Global überall zur Verfügung weil Einstellungen nunmal oft das ganze Projekt betreffen.

    Zurzeit habe ich folgende "Basis-Config-Klasse":
    Spoiler anzeigen
    ​

    C#-Quellcode

    1. ​ public class Config
    2. {
    3. private static Config _defaultConfig = new Config();
    4. public static Config Default
    5. {
    6. get { return _defaultConfig; }
    7. set
    8. {
    9. if (Equals(value, _defaultConfig)) return;
    10. _defaultConfig = value;
    11. }
    12. }
    15. public static void SaveToXML(string _filename)
    16. {
    17. XmlSerializer xs = new XmlSerializer(typeof(Config));
    19. TextWriter txtWriter = new StreamWriter(_filename);
    21. xs.Serialize(txtWriter, Default);
    23. txtWriter.Close();
    24. }
    26. public static void LoadFromXML(string _filename)
    27. {
    28. if (!File.Exists(_filename))
    29. {
    30. Default = new Config();
    31. SaveToXML();
    32. }
    33. else
    34. {
    35. XmlSerializer xs = new XmlSerializer(typeof(Config));
    37. using (Stream reader = new FileStream(_filename, FileMode.Open))
    38. {
    39. Default = (Config)xs.Deserialize(reader);
    40. }
    41. }
    43. }
    44. }


    Dieser füge ich dann Propertys hinzu die gespeichert werden müssen und über Config.Default.PropertyName kann ich dann überall auf die Sache zugreifen.
    Allerdings habe ich in meinem ViewModel natürlich die Propertys doppelt gemoppelt...

    Habe ich z.b. eine View wo man FTP Daten eingibt habe ich in meinem ViewModel dann Propertys für Host, Port, User, Pass
    und in meiner Config ebenso. Beim erstellen der VM setzte ich dann die VM-Propertys immer auf die Werte die in der Config stehen.
    Beim speichern natürlich umgekehrt...

    Die Frage ist: Geht das besser? Denn so habe ich oft "doppelte" Propertys halt einmal in der VM und einmal in der Config.
    Wichtig ist mir halt das ich meine Einstellungen halt da speichern kann wo ich will (am besten neben der Exe).
    Wichtig ist außerdem das ich das ganze natürlich auch in MVVM nutzen kann was jetzt nur so "semi" geil ist wenn ich Einstellungen außerhalb von ViewModels habe.
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen

    @xChRoNiKx Ich habe ein älteres Projekt übernommen, da war auch Redundanz drinne, das ist nicht gut, also raus damit.
    Eine klare Struktur mit mehreren Unter-Settings-Klassen: GUI, Netzwerk, Messung, Auswertung usw., das ist übersichtlich und wartbar.
    Im Programm gibt es eine Instanz dieser Settings, und ich bin am überlegen, ob ich die static mache.
    Wenn von außen auf das Programm zugegriffen wird (Hardware-Konfigurator), wird eine Default-Instanz erstellt.
    Die Geräte-Einstellungen befinden sich in einere anderen (binär-)Datei.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Du meinst also das ich dann halt folgendes habe:

    Settings.GUI.XXXXX
    oder
    Settings.Netzwerk.XXXXX

    XXXXX steht für irgendeine Property
    ?

    Dann würde ich ja auch wieder in den jeweiligen ViewModels da erstmal von der einen auf die andere Property setzen.
    Oder verstehe ich dich da falsch?
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen

    @xChRoNiKx Genau so hab ich das gemeint.
    Das ist insbesondere dann gut, wenn da mehr als 10...15 Properties drinne sind.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das leuchtet mir ein. Danke dafür.

    Aber Punkt 2 bleibt ja dann immer noch.

    Da ich ja nicht an die Static Resource Settings.XXXX.XXXX binden möchte sondern an die Propertys im ViewModel muss
    ich im Konstruktor des ViewModels weiterhin dann die Propertys mit den Inhalten aus der Settings Klasse füllen.
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen

    @xChRoNiKx Sorry, das klingt nach WPF, da hab ich keine Ahnung von.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Da es in Xamarin.Forms funktioniert, gehe ich davon aus, dass es in WPF auch tut:
    @xChRoNiKx bau doch dein SettingsObjekt zu einem "Model" um, das INotifyPropertyChanged Implementiert, und im ViewModel in einer Property hinterlegt ist. Dann kannst du im View über VMProperty.ModelProperty and die Properties des Settingsobjektes binden, ohne zig Properties im VM zu benötigen.

    Hi.

    Ich frage mich auch ob das nur so ein Optimierungs-Dingsie ist oder nicht. :)

    Wenn ich eine Settings View samt ViewModel und Model nutze, dann habe ich immer bei meinen Apps Redundanz.

    Schließlich ist das SettingsModel eher für die Persistenz (Speichern und Laden) Zuständig, und Teilobjekte (Properties) werden den jeweiligen Programmmodulen weiter gegeben.

    Auf ein Singelton kann ich verzichten, weil das Haupt-ViewModel (meist ein 'MainWindowViewModel') nur einmalig eine Eigenschaft für die Settings nutzt.

    Ich bin auch gespannt, ob es eine Viel besserererere Lösung gibt... ;)

    c.u. @all Laden Sie bitte jetzt die Kaffee-Settings-Datei im XML-Format. Grüße aus HH :)

Facebook
Telefonspende