MVVM: Sollte ein VM -Objekt ein M -Objekt direkt oder nur durch Getters, die an Ms Getter delegiert werden, freilegen?

Question

Der beste Weg zu erklären ist mit Beispiel SO:

Dies ist das Modell

public class Person 
{
    public int age;
    public string name;
}

Dies ist das Ansichtsmodell

public class PersonVM
{    
}

meine Frage ist:
Sollte die VM die Person der Datenvorlage aussetzen oder die Modelleigenschaften mit ihren eigenen Eigenschaften zusammenfassen?

Answer 1

Das Ansichtsmodell sollte seine eigenen Eigenschaften deklarieren und die Besonderheiten des Modells aus der Ansicht verbergen. Dies gibt Ihnen die größte Flexibilität und hilft, die Probleme mit dem Ansichtsmodell daran zu hindern, in die Modellklassen einzugehen. Normalerweise umfassen Ihre Ansichtsmodellklassen das Modell durch Delegation. Zum Beispiel,

class PersonModel {
    public string Name { get; set; }
}

class PersonViewModel {
    private PersonModel Person { get; set;}
    public string Name { get { return this.Person.Name; } }
    public bool IsSelected { get; set; } // example of state exposed by view model

    public PersonViewModel(PersonModel person) {
        this.Person = person;
    }
}

Denken Sie daran: Das Modell sollte nichts über das View -Modell wissen, das es verbraucht, und das View -Modell sollte nichts über die Ansicht wissen, die es verbraucht. Die Ansicht sollte nichts über die Modelle wissen, die im Hintergrund lauern. In den Eigenschaften des Ansichtsmodells einkapseln.

Answer 2

Es gibt keine allgemeine Vereinbarung zu dieser Frage. Zum Beispiel war es eine der offenen Fragen zu MVVM, die von Ward Bell formuliert wurden hier:

Dürfen die VM dem V ein ausgepacktes M-Objekt (z. B. den rohen Mitarbeiter) anbieten? Oder müssen die Eigenschaften des M-Objekts (wenn es überhaupt Eigenschaften haben darf!) Ausschließlich durch die Oberfläche eines VM-Wrappers freigelegt werden?

Die Hauptvorteile, das Modell in der VM nicht direkt aufzudecken, sind:

• Sie können es als "Konverter für Steroide" verwenden und die Modellwerte auf bequeme Weise für die Ansicht formulieren

• Sie können andere Funktionen in Bezug auf die Benutzeroberfläche injizieren, wie Datenvalidierungsmeldungen, rückgängig wiederholen,..

Die Nachteile sind:

• Sie müssen viel Code duplizieren, um alle Modelle Eigenschaften im ViewModel freizulegen.

• Wenn Sie die Ansichtskontrolle an die Eigenschaft viewModels -Eigenschaft binden, senden Sie die PropertyChanged -Ereignisse aus dem ViewModel. Aber was passiert, wenn sich die Eigenschaft der Modelle von einer anderen Quelle ändert, die sich vom ViewModel Setter unterscheidet? Dann muss es das ViewModel benachrichtigen, damit Sie mit 2 On -Propertychanged, einem im Modell und einem im ViewModel ... ziemlich komplex!

Für mich lautet die richtige Antwort: Es hängt von Ihren Anforderungen ab.

Answer 3

Eine interessante Lösung dafür wurde von Robert McCarter in MSDN Band 25 vorgeschlagen.

http://msdn.microsoft.com/en-us/magazine/ff798279.aspx

Er verwendet ein dynamisches Ansichtsmodell, um eine Ebene über dem Modell bereitzustellen und gleichzeitig alle Modelleigenschaften zu vermeiden.

Wenn Ihr Problemraum keine hohe Leistung erfordert (Dynamics erscheint einen Leistungstreffer), ist dies eine hervorragende Lösung. Die Ansicht muss nichts über das Modell wissen, aber das Ansichtsmodell muss keine Proxy -Eigenschaften, die "so wie es ist" bereitgestellt werden. Zu jedem Zeitpunkt können Eigenschaften zum Ansichtsmodell hinzugefügt werden, um die Modelleigenschaften zu wickeln, ohne die Ansicht oder das Modell zu ändern. Lesen Sie den Artikel für weitere Details.

Answer 4

Ein ViewModel für ein Modell könnte schlechter sein. Was ist, wenn Sie eine hierarchische Struktur eines Modells oder sogar eine einfache Sammlung haben? In diesem Fall müssen Sie alle Modelle durchführen und eine ViewModel-Instanz pro Model erstellen und auch die Benachrichtigung von Ereignissen oder anderen Ereignissen registrieren. IMHO, das ist völlig verrückt und unvernünftig. Wie Danice sagte, werden Sie viel Code und große Kopfschmerzen haben.