MVC: Zwei Views fürs selbe Model -> Update?



  • Hi,

    Edit:
    Mittlerweile ist das andere Thema ausgeartet und damit ein Crosspost, der Thread hier kann also weg. Der andere Thread ist:

    https://www.c-plusplus.net/forum/334559

    Text:
    sagen wir, ich habe ein MVC-Modell mit zwei Views für ein Model habe, weil ich z.B. Daten einmal als Text und einmal via Diagramm darstellen möchte. Änderungen sind erlaubt, sollen aber natürlich live auch im anderen View dargestellt werden.

    Beispiel: Ich habe eine Reihe von Zahlen, die in View1 als textbasierte Liste und in View2 als Säulendiagramm darstellen möchte. In View1 kann ich die Zahlen einzeln über die Tastatur ändern. In View2 kann ich die Säulen durch die Maus mit irgendwelchen Gesten größer oder kleiner ziehen.

    Üblicherweise sollte eine Änderung in einem View einfach an das Model mitgeteilt werden. Dieses ist dann dafür zuständig, dass die anderen Views über die Änderung informiert werden.

    Jetzt zur (eigentlich einfachen) Frage:
    Wie setzt ihr (z.B. mit QT in C++, gerne auch mit anderen Sprachen) um, dass NICHT Folgendes passiert:

    1. View1 wird vom User angepasst
    2. Änderung wird ins Model übertragen
    3. Model alarmiert alle angemeldeten Views (z.B. über Signal/Slot oder Observer)
    4. somit wird auch View1 alarmiert und geupdated (eigentlich unnötig!)
    5. die "Änderung" wird dem Model mitgeteilt und das alarmiert wieder alle Views usw.

    Endlosschleife also. Ich überlege gerade, wie ich es schön gestalte, damit das nicht passiert. Wie macht ihr das? Hier sind ein paar Vorschläge:

    A)
    Sollte einem View eine "Änderung" mitgeteilt werden, wird geprüft, ob der neue Wert nicht dem alten entspricht. Falls ja, wird nichts weiter getan. (Nachteil: dem View wird vom Model trotzdem eine Änderung mitgeteilt, auch wenn der diese ignoriert)

    😎
    Das Model prüft bei dem Wert, ob er anders ist, als der alte. (Nachteil: View1, in dem etwas vom User geändert wurde, wird zumindest ein weiteres mal unnötig alarmiert)

    C)
    Das Model bietet eine Möglichkeit herauszufinden, wer den Aufruf getätigt hat. Es wird dann nur alarmiert, wer nicht den Aufruf tat. (Nachteil: der Mechanismus ist vermutlich unschön; vermutlich bräuchte jeder View eine Art ID, die dann auch das Model kennen muss; das lässt sich dann auch nicht mehr mit einer einfachen signal/slot-Beziehung realisieren)

    D)
    irgendwas anderes...

    Bin sehr gespannt, wie ihr das umsetzt. Ich arbeite gerade bereits mit einer bestimmten Variante, finde das jedoch nicht schön.

    Gruß
    Eisflamme


Anmelden zum Antworten