Wie CRUD Master Details auf dem gleichen Bildschirm unter MVVM

Question

implementieren Ich habe eine MVVM (Prism) -Anwendung, die ich implementieren muss ein Master-Details Bildschirm, wo der Master eine Listview ist und die Details neben angezeigt wird. Read-Only scheint einfach genug zu sein (habe es noch nicht gemacht, aber ich habe den Kopf um WPF gebunden), aber edit/add verwirrt mich.

Wie mache ich es so, dass der Master nicht aktualisiert wird, bis die Details gespeichert sind? Wie stelle ich es so ein, dass Sie die aktuelle Auswahl des Masters im Bearbeitungsmodus nicht ändern können?

Ich habe eine Menge googlen, aber habe keine fleischigen Beispiele dafür gefunden.

Danke.

PS: Diese Ansicht ist eine Kinderansicht auf einem größeren Bildschirm. Deshalb möchte ich sowohl Master als auch Detail zusammen.

Answer 1

Danke für die Antwort. Jetzt habe ich meine Nachricht erneut gelesen, ich sehe, dass sie ziemlich vage ist. Ich habe einen Bildschirm, der ein Objekt bearbeitet, das mehrere Listen anderer untergeordneter Objekte enthält. Ich habe diese als verschiedene Registerkarten in einem Tab-Steuerelement implementiert. Eine dieser Registerkarten bearbeitet die Kommentare. Daher wollte ich eine Liste von Kommentaren mit einem Bearbeitungsfeld für die aktuelle Auswahl neben der Liste anzeigen. Der Benutzer könnte dann Schaltflächen hinzufügen, bearbeiten oder löschen verwenden, um die Liste zu aktualisieren. Ich wollte das auf eine reine (ish) MVVM-Art machen.

Ich kam mit dem folgenden Design, das mit minimalen Hacks zu arbeiten scheint.

Die Ansicht enthält eine Liste der untergeordneten Objekte einfach als ListView, das an eine beobachtbare Sammlung innerhalb des ViewModel gebunden ist. Ich habe einen Child-Objekt-Puffer hinzugefügt - dieser wird verwendet, um Änderungen zu puffern, bis sie wieder in der Liste gespeichert (oder weggeworfen) werden können.

Die Ansicht enthält auch ein Bearbeitungsfenster, das an das Pufferobjekt im ViewModel gebunden ist. Der Puffer wird aktualisiert, wenn sich die aktuelle Auswahl der Listenansicht mit einer tiefen Kopie ändert. Ich habe versucht, Datenbindung für die Selecteditem-Eigenschaft zu verwenden, aber die Menge wurde nie aufgerufen. Daher wurde eine kleine CodeBehind-Methode hinzugefügt, um zu erzwingen, dass die Eigenschaft aktualisiert wird, wenn die Auswahl geändert wurde.

Die Listenansicht und Bearbeitungsansicht schließen sich gegenseitig aus. Theoretisch könnte man den Behinderten verstecken, vielleicht mit einem Flip-Screen. Als generelles Muster ist es für meine App besser, beide gleichzeitig sichtbar zu haben, da das Bearbeitungsfeld zusätzliche Informationen anzeigen kann, die in der Listenansicht nicht angezeigt werden. Die Auswahl, welches Fenster aktiviert wird, wird durch die Bindung von IsEnabled an eine ViewModel-Eigenschaft wie IsEditCommentMode gesteuert.

Befehle zum Verwalten der Liste müssen hinzugefügt werden, das sind Neu, Bearbeiten und Löschen. Beachten Sie, dass Add und Edit den Puffer einrichten und dann IsEditCommentMode auf true setzen. Diese Befehle zur Listenverwaltung sind nur verfügbar, wenn IsEditCommentMode den Wert false hat. Das Bearbeitungsbedienfeld implementiert Befehle zum Speichern und Abbrechen, sie werden nur aktiviert, wenn IsEditCommentMode den Wert true hat. Wenn Save ausgeführt wird, sollte es aus dem Puffer in die Liste kopieren (entweder hinzufügen oder aktualisieren) und die Änderungsbenachrichtigung auslösen. Schließlich sollte es IsEditCommentMode auf false festlegen.

Das alles funktioniert gut und scheint keine MVVM Tenents zu verletzen (in meiner bescheidenen aber oft fehlerhafte Meinung).

Answer 2

Sie können dies sicherlich tun, obwohl meiner Meinung nach ein solches UI-Design die volle Leistung von WPF nicht nutzen kann. Alte WinForms-UIs haben den Großteil der Anwendung normalerweise nicht aktualisiert, bis Daten in SQL Server (oder wo auch immer) gespeichert wurden, da sie keine echten Geschäftsobjekte und ein mächtiges Bindungssystem wie WPF hatten. Der Versuch, WinForms-Einschränkungen innerhalb von WPF zu kopieren, scheint mir ein Schritt zurück zu sein. Warum werden die neuesten Daten nicht überall dort angezeigt, wo sie in der Benutzeroberfläche angezeigt werden, auch in der Masteransicht? Warum sollten Sie dem Benutzer nicht erlauben, vor dem Speichern mehrere Elemente zu bearbeiten, z. B. das Markieren eines bearbeiteten, nicht gespeicherten Elements mit einem animierten Marker in der Master-Ansicht? Kombinieren Sie diese mit einem generalisierten Undo und Sie haben ein besseres Design und intuitiver für den Benutzer.

Allerdings, wenn Ihre Geschäftsanforderungen machen es absolut notwendig, ist hier, wie es geht:

Verhindern von Änderungen an Daten von außerhalb des Details sichtbar zu sein, bis er

Nach dem Eintritt in denen gespeichert wird " edit/add mode ", erstellen Sie eine Kopie der Datenobjekte und stellen Sie den DataContext der Detailansicht auf die Kopie statt auf das Live-Objekt ein. Wenn die Daten "gespeichert" sind, kopieren Sie die Daten aus der Schattenkopie zurück in das Live-Objekt und stellen Sie den DataContext der Detailansicht an die gewünschte Position zurück.

der aktuellen Auswahl des Master verhindert im Bearbeitungs Ändern/add-Modus

Zwei Möglichkeiten:

1. Während bearbeiten/add-Modus, die Master-Ansicht wechseln Maus nicht zulassen Treffertests oder Tastatur focus

2. Wenn der Bearbeitungs-/Hinzufügemodus beginnt, erfassen Sie die "aktuelle Auswahl" und fügen Sie dann einen Ereignishandler hinzu, der nach Änderungen der "aktuellen Auswahl" sucht und diese sofort ändert s die Auswahl zurück zu dem, was es war. Wenn der Bearbeitungs-/Hinzufügen-Modus endet, entfernen Sie den Handler. Dieser Handler kann bequem unter Verwendung eines Lambda-Ausdrucks und unter Verwendung eines Abschlusses für eine lokale Variable zum Speichern der aktuellen Auswahl codiert werden.