Ich mache die ersten Schritte in das MvvmCross-Framework und versuche, den besten Ansatz hinsichtlich der Projekt- und Klassenstruktur zu finden. Meine größte Sorge ist jetzt, zu entscheiden, wie ich meine Viewmodels organisieren soll, um Daten zwischen ihnen zu teilen und gleichzeitig die mvvm-Anleitung zu befolgen.
Ich habe ein einfaches Beispiel mit Views und entsprechenden Viewmodels (Main und Configuration). Die Hauptansicht enthält einige Steuerelemente, die an Eigenschaften im Ansichtsmodell gebunden sind. In der Konfigurationsansicht kann der Benutzer die Textfarbe, die Anzahl der Elemente in der Liste usw. ändern. Wenn der Benutzer die Konfiguration ändert, sollte dies in der Hauptansicht angezeigt werden.
Mein erster Ansatz war, separate Ansichts- und Ansichtsmodelle zu erstellen. Aber wie kann ich die Hauptansicht darüber informieren, dass die Konfiguration geändert wurde? Ich habe das Sphero-Projekt unter Github / Slodge gesehen und festgestellt, dass ein Ansichtsmodell direkte Verweise auf andere Ansichten hat. Auf diese Weise ist es relativ einfach, die Hauptansicht jedes Mal zu melden, wenn sich die Konfiguration ändert. Aber ist das nicht eine Abweichung der entkoppelten Ansichtsmodelle, die mvvm empfiehlt?
Könnte ich ein paar Einsichten darüber bekommen, wie man diese Art der Klassenstrukturierung am besten angehen kann?
Der beste Weg, um diese Art der Klassenstrukturierung zu erreichen
Meiner Meinung nach besteht die wichtigste Maßnahme für "den besten Weg" darin, einen Weg zu wählen, der bedeutet, dass Ihre App funktioniert.
Das Beispiel, das Sie sich angeschaut haben - sphero ball control - hat Beispiele für beide unabhängige Ansichtsmodelle (home, gangnam, about, sphero usw.), und es gibt ein Beispiel für einige Ansichtsmodelle, die voneinander wissen - die Sphero-View-Modell und seine Sub-View-Modelle.
In diesem speziellen Fall ist der Grund dafür, dass diese Ansichtsmodelle alle voneinander wissen, dass sie alle Teil einer einzigen Anzeige sind - sie sind so konzipiert, dass sie in einem einzigen Raster-, Pivot- oder Registerkarten-UI zusammen sitzen. Um ihnen bei der Zusammenarbeit zu helfen, habe ich ihnen Referenzen über IParent und IChild-Schnittstellen gegeben.
ist das nicht eine Abweichung der entkoppelten Ansichtsmodelle, die mvvm empfiehlt?
Ich gebe zu, dass dies bedeutet, dass das Design nicht perfekt entkoppelt ist und dass ich, wenn ich diese Kind-VMs in Zukunft verschieben oder wiederverwenden muss, ein wenig Code-Refactoring machen muss - aber im Moment funktioniert das Design Gut für mich, und ich persönlich bin glücklich, dass das Refactoring in Zukunft tun, wenn ich muss.
Meine größte Sorge ist jetzt, zu entscheiden, wie ich meine Ansichtsmodelle organisieren soll, um Daten zwischen ihnen zu teilen und gleichzeitig der mvvm-Anleitung zu folgen
Wenn Sie eine zusammengesetzte Ansicht (mit Registerkarten) erstellen und nicht mit aggregierten Ansichtsmodellen (wie dem Sphero vm und den Unteransichten) zufrieden sind, dann tun Sie dies bitte nicht.
Ich bin mir sicher, dass der gleiche Effekt in Sphero mit einem großen Ansichtsmodell erzielt werden könnte, indem mehrere Ansichtsmodelle über einen Messenger kommunizieren oder mehrere Ansichtsmodelle verwenden, die über einen oder mehrere benutzerdefinierte Dienste kommunizieren.
Für das spezielle Beispiel, das Sie geben - von einer Konfiguration und einer Hauptansicht, glaube ich nicht, dass dies dem Tabbed-Szenario entspricht - und ich würde das wahrscheinlich mit einem Messenger kodieren -, der mir einen flexiblen Mechanismus zum Senden und Empfangen zur Verfügung stellen würde Benachrichtigungen für verschiedene Teile der App ändern.
Allerdings sind andere Designs definitiv verfügbar und praktikabel - zB könnte man einfach das View-Modell bitten, seine Konfiguration jedes Mal zu aktualisieren, wenn es angezeigt wird (dies würde das Einbinden in onnavigatedto-, viewwillaperare- und wiederaufgenommene Aufrufe in den Ansichten erfordern).
Zusammenfassend:
In dem Projekt, das ich mit MvvmCross erstelle, entschied ich mich, View-Modelle zu verwenden, um die Ansichten (Bildschirme) und ihren Status darzustellen. Meine Viewmodels sind über ISQLiteConnectionFactory mit der SQLite-Datenbank verbunden. Ich verwende Modelle, die in der SQLite-Datenbank gespeichert sind, um den Zustand der Dinge im Projekt darzustellen. Meine Ansichtsmodelle erhalten die Modelle aus der SQLite-Datenbank, analysieren sie und reagieren darauf.
Beispiel. Ich habe einen Bildschirm, auf dem ein Benutzer kennzeichnen kann, dass er ein Stück Daten auf dem Gerät heruntergeladen möchte. Mein Modell hat eine Markierung, ob das betreffende Teil der Daten heruntergeladen werden soll oder ob es heruntergeladen wurde. Wenn ich einen anderen Bildschirm öffne, der für das Herunterladen von Daten zuständig ist, sucht er in SQLite nach, ob irgendwelche Modelle zum Herunterladen markiert sind und reagiert darauf.
So habe ich mich entschieden, die Daten zwischen Viewmodels zu teilen. Der Vorteil besteht darin, dass Daten immer in der Datenbank gespeichert werden. Das Schließen einer App führt nicht zu Datenverlusten (oder etwas, was nicht wie erwartet geschieht).
Tags und Links structure viewmodel mvvmcross decouple sphero-api