Model-View-ViewModel Musterverletzung von DRY?

Question

Ich lese diesen Artikel heute http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx über die Verwendung des MVVM-Musters in einer Silverlight-App, wo Sie Ihre Domain-Entitäten und sehen spezifische Entitäten, die im Grunde eine Teilmenge der realen Entitätsobjekte ist. Ist das nicht eine klare Verletzung des DRY-Prinzips? und wenn ja, wie kannst du damit gut umgehen?

Answer 1

Persönlich mag ich nicht, was Dino da macht und ich würde das Problem nicht auf die gleiche Weise angehen. Normalerweise denke ich an eine VM als eine gefilterte, gruppierte und sortierte Sammlung von Modellklassen. Eine VM für mich ist eine direkte Zuordnung zur View, daher könnte ich eine NewOrderViewModel-Klasse erstellen, die mehrere CollectionViews für die View verwendet (möglicherweise einen Lebenslauf für Kunden und einen anderen Lebenslauf für Produkte, wahrscheinlich beide gefiltert). Das Erstellen einer völlig neuen VM-Klasse für jede Klasse im Modell verstößt meines Erachtens gegen DRY. Ich würde eher die Ableitung oder partielle Klassen verwenden, um das Modell bei Bedarf zu ergänzen, indem ich View-spezifische (oft berechnete) Eigenschaften hinzufüge. IMO .NET RIA Services ist eine hervorragende Implementierung der Kombination von M- und VM-Daten mit dem zusätzlichen Bonus, dass es sowohl auf dem Client als auch auf dem Server verwendet werden kann. Dino ist ein brillanter Typ, aber eine Art, ihn anzurufen.

Answer 2

DRY ist ein Prinzip, keine harte Regel. Du bist ein Mensch und kannst dich unterscheiden. Zum Beispiel Wenn DRY wirklich eine harte Regel wäre, würden Sie niemals zwei Variablen denselben Wert zuweisen. Ich nehme an, in jedem nicht trivialen Programm hätten Sie mehr als eine Variable, die den Wert 0 enthält.

Generell gilt: DRY trifft normalerweise nicht auf Daten zu. Diese ansichtsspezifischen Einheiten wären wahrscheinlich nur Datenübertragungsobjekte ohne nennenswerte Logik. Daten können aus verschiedenen Gründen dupliziert werden.

Answer 3

Ich denke, die Antwort hängt wirklich davon ab, was Sie im ViewModel sein sollten. Für mich repräsentiert das ViewModel das Modell des gerade angezeigten Bildschirms.

So etwas wie ein ViewCategoryViewModel, ich habe keine Verdoppelung der Felder in der Kategorie. Ich exponiere ein Category-Objekt als eine Eigenschaft auf dem ViewModel (unter "SelectedCategory"), alle anderen Daten, die die Ansicht anzeigen muss, und die Befehle, die dieser Bildschirm ausführen kann.

Es wird immer eine gewisse Ähnlichkeit zwischen dem Domänenmodell und dem Ansichtsmodell geben, aber alles hängt davon ab, wie Sie das ViewModel erstellen.

Answer 4

Es ist das gleiche wie bei Data Transfer Objects (DTO).

Die Domäne für diese beiden Objekttypen unterschiedlich ist, so es von DRY nicht eine Verletzung ist.

Betrachten Sie das folgende Beispiel:

class Customer 
{ 
    public int Age 
} 

Und ein corsponding Ansicht Modell:

class CustomerViewModel 
{ 
    public string Age; 

    // WPF validation code is going to be a bit more complicated: 
    public bool IsValid() 
    { 
     return string.IsNullOrEmpty(Age) == false; 
    } 
} 

Differnt Domains - differnet Immobilienarten - verschiedene Objekte.