Optionsdialog WPF + MVVM + Observable Collection

  • WPF

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Optionsdialog WPF + MVVM + Observable Collection

    Hallo Leute,

    Ich tüftle gerade an einem Optionsdialog für mein Programm und stehe vor einem Problem.

    Zur Erkläung: Das Programm arbeitet mit mehreren Datenbanken die über einstellbare Vorgaben verfügen: z.b. Datumsanzeige udg. die Optionen sind in einer Tabelle innerhalb der DB gespeichert. info_v01 die eine info_id eine "bezeichnung" und den "wert" der Einstellung als String beinhaltet das EntityFramework zur Klasse sieht so aus:

    VB.NET-Quellcode

    1. ​
    2. Imports System
    3. Imports System.Collections.Generic
    4. Imports System.Collections.ObjectModel
    6. Partial Public Class info_v01
    7. Public Property info_id As Integer
    8. Public Property bezeichnung As String
    9. Public Property wert As String
    11. End Class


    Es gibt dzt. ca. 18 Einstellung jede hat ihre forlaufende info_id sowie eine eindeutige bezeichnung z.b. "doc_use_subfolder" und den Wert 1 (als String)

    Derzeit schaut meine Lösung so aus die Bindung meines Optionsdialoges geht direkt auf die Observable Collection und ich greife im Binding auf die "Position" der Einstellung innerhalb der Collection zu:
    z.B.

    XML-Quellcode

    1. ​
    2. <CheckBox x:Name="chk_subfolder" Margin="3" DockPanel.Dock="Left" IsChecked="{Binding .[7].wert, Converter={StaticResource cls_string_2_boolean_converter}}" VerticalAlignment="Center"/>


    Das Problem in meinen Augen ist das dieses System sehr fehleranfällig ist da ich nicht zu 100% sicher sein kann das die Werte sich nicht verschieben und dadurch der Optionsdialog "kaputt" geht.

    Daher meine Frage wie könnte ich die Sache besser und fehlersicherer gestalten?
    Ich hab schon überlegt ob ich beim Dialog laden nicht das Binding im Codebehind auf Basis der "bezeichnun" zuweisen soll aber das erscheint mir als wenig praktikabel....

    Vielleicht kann mir jemand einen Tipp geben.
    danke!
    mfG.
    Stephan

    Das würde Sinn machen aber der Aufwand ist schon relativ enorm ich glaub ich werde aber diesen weg gehen müssen ein ansprechen der Eigenschaften im Dialog nach dem Prinzip "Hoffnung" ist mir doch zu riskant.

    Danke für den Tipp.
    mfG.
    Stephan

    vielleicht auch nicht.
    evtl. brauchst du nicht ein Extra-ViewModel, sondern dein derzeitiges Viewmodel muss halt viel differenzierter ausfallen.

    Zu einer Name-Property musses dann eine NameDisplayWidth - Property geben und Zeugs.

    Das ist eben fundamental anders als in WinForms, wo man viel eher ein Optionen-Model erstellen kann, wo dann alle Control-Eigenschaften persistiert werden.

    Oder man gibt MVVM nu einen Tritt, und legt UI-Optionen auch tatsächlich im UI an.

    Also ich bin da voll unentschieden.
    UI-Optionen sind eiglich nichts, was gebunden sein sollte.
    Sondern das wird gespeichert, bzw. das Gespeicherte wird einmal angewendet (oder auch mehrmals). Jedenfalls sind das keine Daten, die mittels Bindings ständig synchron zu halten wären.

    Sorry - ich verschaffe dir wohl kaum Klarheit.
    Ich bräuchte ein konkretes lauffähiges Beispiel mit klarer, nicht zu einfacher Anforderung, da würde mir evtl. was zu einfallen.
    Hast du eiglich auch mal gegoogelt? vlt. hat sich auf Codeproject ja schon jemand dieses Themas angenommen.

    Ich hab ziemlich viel rumgesucht aber so wirklich praktikable Lösungen habe ich nicht gefunden.

    Ich habe jetzt einen Mittelweg gemacht und mir eine Klasse erzeugt die alle Einstellungen beinhaltet diese wird einfach mit dem Mainmodel synchron gehalten.

    Der Vorteil hierbei ist das die Zuweisung der Optionen bzw. der Gebrauch der Optionen im Mainmodel sehr simpel ausfällt da die Properties offen liegen.

    Einziger Nachteil um eine neue Option zu erstellen muss ich eine neue Property erzeugen damit kann ich leben ich verwalte hier nur 20 Einstellung und nicht 2000 und mehr.

    Danke trotzdem für deinen Denkanstoß.
    mfG.
    Stephan

    Auf jeden Fall ein interessantes Problem.
    Sowas wie Spaltenbreiten eines Datagrids sind ja normalerweise keine Daten, die persistiert werden sollen, sondern sind Status der Oberfläche.
    Und Spaltenbreiten sollten eiglich nicht synchron gehalten werden, sondern erst beim Schließen ist das abzuspeichern, und zum Starten ist das einmalig zu laden und anzuwenden.

    Und es bewegt sich auch ausserhalb von MVVM, wie gesagt: statt laufender Synchronisation per Databinding ist streng genommen eine Store/ApplyStorage - Logik gefragt.
    Für Winforms habich da was hübsches gebastelt: ComplexConverter: alles in einen String und zurück?
    Und es müsste genau das machen, was MVVM nicht soll, und was der große Unterschied zu WinForms ist: Nämlich dass Code aufs View zugreift (zumindest bei Spaltenbreiten).

    Zur Store/ApplyStorage - Logik:
    Die müsste zum ShutDown den Oberflächen-Status speichern können, und zum Startup wieder rekonstruieren.
    Ausserdem müssen auch klassische Optionen in den Storage hinein, ob die Datums-Anzeige sichtbar ist, Farbgebung, gesetzte Filter und so Kram.

    Jo, so sähe ich das ideale und wiederverwendbare Konzept davon, aber ist wirklich Frage, ob das jetzt für dein Einzelfall unbedingt perfekt umgesetzt werden muss.

Facebook
Telefonspende