[MVVM][Prism] Mehrere ViewModels in einer Transaktion speichern?

asc

Ich muss mich relativ schnell in eine komplexere Materie einarbeiten, daher kann es sein, das ich einfach noch kein praktisches Beispiel entdeckt habe...

Die meisten MVVM-Frameworks (wozu ich u.a. auch Prism zähle, wenn gleich dies weit mehr kann) versuchen eine möglichst lose Kopplung zu erreichen. Nun kann es aber sein, das z.B. mehrere verschiedene ViewModels, bezogen auf die Datenhaltung, doch zusammen gehören (z.B. ein Bearbeitenfenster das viele getrennte Bereiche hat, die aber nur als ganzes gespeichert werden sollten).

Wie schafft man hier das gewisse Teile als Einheit bei der Speicherung zusammen gehören, ohne eine zu starre Kopplung zu erreichen, und gleichzeitig bestimmte Bereiche auch wieder getrennt zu betrachten.

Beispiel: Neben wir einfach einmal an das eine Anwendung mehrere Tabs anzeigt, die jeweils einen "logischen" Datensatz darstellen (z.B. eine Person). Jedes Tab ist wiederum aber aus mehreren Einheiten zusammen gesetzt (z.B. Mehrere Anschriften zu der Person). Die Daten jeder Person müssen gemeinsam gespeichert werden, haben aber erst einmal nichts mit den anderen Personen zu tun.

Begriffe wie Unit of Work sind mir zwar prinzipiell bekannt, die Verknüpfung fällt mir aber noch schwer... (Nach meinen Verständnis würden die Teildaten einer Person, eine Instanz einer solchen Unit of Work teilen müssen, wie die Zusammensetzung erfolgt ist mir aber z.B. noch nicht ganz klar).

Ich habe leider noch keine Lektüre gefunden die wirklich mal alle relevanten Bereiche einer Anwendung an einem kleinen durchgängigen Beispiel zusammenführt, und dennoch auch etwas komplexere Szenarien wie zusammengehörige ViewModels betrachtet.

Das Thema MVVM wird aber leider auch nur mit Samthandschuhen in der Bücherwelt angefasst, und im Internet scheint jeder eine eigene Vorstellung davon zu haben (Beginnend schon mit Themen ob das Model nun Logik enthalten sollte oder nicht, wie man die View zu einem ViewModel bindet...).

Dravere

Was spricht denn gegen sowas?

public class PersonViewModel
{
  private List<AddressViewModel> m_addresses;

  public IEnumerable<AddressViewModel> Addresses { get { return m_addresses; } }
}

Grüssli

asc

Dravere schrieb:

Was spricht denn gegen sowas?

public class PersonViewModel
{
  private List<AddressViewModel> m_addresses;

  public IEnumerable<AddressViewModel> Addresses { get { return m_addresses; } }
}

Grüssli

Dagegen spricht das bestimmte Informationen erst später (sowohl bezogen auf die Laufzeit als auch bezogen auf die Entwicklung) hinzu kommen und konfigurierbar sind.

Bei mir gibt es beispielsweise einen Kontakt, was in der Regel eine Firma oder eine Person ist, die beliebige Adressen hat (soweit noch einfach), nun gibt es aber viele Teile die nur mit bestimmen Erweiterungen und einer bestimmten Rolle Sinn machen (z.B. Wenn es sich bei den Kontakt um einen Dozenten handelt noch Informationen wie die zu leistenden Veranstaltungsstunden...; Datenbankseitig sieht dies so aus das die abhängigen Elemente auf den Basisdatensatz verweisen).

Hier bietet sich vom bisherigen Verständnis Prism recht gut an, da ich ein sehr modularen Ansatz verfolge. Ich bin inzwischen so weit, das ich glaube die Lösung gefunden zu haben. In Prism kann man einer Region die aus mehreren Views besteht gemeinsame Daten über einen RegionContext halten (In meinen Fall beispielsweise einen Verweis auf den jeweiligen Basisdatensatz und beispielsweise den DbContext zu halten, über den die Speicherung erfolgt...).