MVVM-Standardisierung

Question

Jemand in Silverlight veröffentlicht dass es MVVM derzeit an Standardisierung fehlt, so dass jeder seinen eigenen Geschmack hat

Das ist der Grund, warum ich und ein paar Jungs von WPF Disciples sind aktiv zu diskutieren, welche Elemente von MVVM, dass jeder vereinbart. Ich verstehe vollkommen, dass wir das Muster auf unterschiedliche Art und Weise implementiert haben und wir haben die verschiedenen Muster gemischt oder unsere eigenen Muster basierend auf den Bedürfnissen unseres Projekts erstellt oder um das Leben der Entwickler einfacher zu machen. Aber vergessen Sie diese Schwierigkeiten oder die speziellen Anforderungen Ihres Projekts. Lassen Sie uns über die Standardregeln des MVVM-Musters diskutieren, über die sich alle einig sind. Ich habe gepostet einige meiner Gedanken hier auch.

Warum MVVM?

• Testbarkeit (ViewModel ist einfacher zu testen als Code-Behind oder ereignisgesteuerter Code)
• Klare Trennung zwischen UX-Designer und Entwickler
• Erhöht die "Überblendbarkeit" Ihrer Ansicht
• Das Modell muss nie geändert werden, um Änderungen an der Ansicht zu unterstützen.
• Das ViewModel muss nur selten geändert werden, um Änderungen an der Ansicht zu unterstützen.
• Kein doppelter Code zur Aktualisierung von Ansichten

Do and Don't in View

• sollte keine Logik enthalten, die Sie testen wollen: Wie Glenn sagte, ist MVVM keine Code-Zählübung, wir können Code in Code-Behind schreiben. Aber Sie sollten niemals eine Logik schreiben, die Sie testen wollen. Zum Beispiel: Wenn der Benutzer ein Land auswählt, möchten Sie die Liste der Staaten oder Städte in Ihrer Ansicht anzeigen. Dies ist die Geschäftsanforderung, so dass Sie Unit-Tests haben sollten, um diese Logik zu testen. Sie sollten sie also nicht in Code-Behind schreiben.
• kann ein Steuerelement oder eine Datenvorlage sein
• Halten Sie die Ansicht so einfach wie möglich: Wir können immer noch Data Trigger oder Value Converter oder Visual State oder Blend Behivor in XAML mit Vorsicht verwenden.
• Verwenden Sie die angehängte Eigenschaft, wenn etwas nicht bindungsfähig ist:

Do und Don't im ViewModel

• Verbindung zwischen Ansicht und Modell
• Keep View State, Value Conversion (Sie können die Datenstruktur, die Sie in ViewModel anzeigen möchten, statt mit ValueConverter erstellen. Zum Beispiel: Sie müssen den Namen anstelle von Vorname und Nachname anzeigen. Ihr Model kann Vornamen und Nachnamen haben, aber Sie können die Eigenschaft Name im ViewModel erstellen. )
• Kein starker oder schwacher (über die Schnittstelle) Bezug der Ansicht
• VM so testbar wie möglich machen (z.B. kein Aufruf der Singleton-Klasse)
• Kein Control related Stuff in VM (Wenn Sie die Ansicht ändern, müssen Sie auch VM ändern. )

Modell

• kann ein Datenmodell, ein DTO, ein POCO, ein automatisch generierter Proxy einer Domänenklasse und ein UI-Modell sein, je nachdem, wie Sie die Trennung zwischen Domänendienst und Präsentationsschicht wünschen
• Kein Verweis auf ViewModel

Haben Sie dazu eine Anregung oder einen Kommentar?

Wir haben eine Meinungsverschiedenheit in unserer Fraktion. Einige sagten, dass es in Ordnung ist, die Schnittstelle von View in ViewModel zu haben. Aber einige sagten, wenn View Model die Schnittstelle von View hat, dann wird es MVP-Muster sein.

Einer unserer MVVM-Experten sagt über MVVM Vs MVP

Ansicht => ViewModel

• MVVM ist die Ansicht direkt an das ViewModel gebunden und spricht mit der VM durch Datenbindung
• In MVP ist die Ansicht an ein Modell gebunden, das am SupervisingController hängt, oder überhaupt nicht gebunden (passive Ansicht).

ViewModel => Ansicht

MVVM

1. INPC / Immobilienbindung
2. Veranstaltungen
3. Nachrichten (Ereignis-Aggregator/Messenger/RX-Rahmen)
4. Über einen Vermittler, z. B. einen Dienst
5. Über eine Schnittstelle
6. Über Delegaten (View übergibt Delegaten an die VM, die sie zum Rückruf verwenden kann. Zum Beispiel könnte die VM eine SetActions-Methode bereitstellen, die die View aufruft, indem sie ihr Delegates übergibt.

MVP

Im MVP-Fall ist der Standard, dass der Presenter mit der Ansicht entweder über eine Schnittstelle, Datenbindung oder über Eigenschaften im Fall der passiven Ansicht kommuniziert. Bei der passiven Ansicht verwenden die Eigenschaften keine Datenbindung, stattdessen werden die Getter und Setter der Ansichtseigenschaften verwendet, um den Wert des Steuerelements direkt einzustellen.

Was halten Sie von dieser Idee?

Glauben Sie, dass es in Ordnung ist für ViewModel haben die Schnittstelle von View?

Wenn Sie mehr hinzufügen möchten, können Sie das gerne tun... :)

Die ganze Idee zu diesem Beitrag ist es, das gleiche Verständnis von MVVM-Muster in der Gemeinschaft zu bekommen.

Answer 1

Mir gefällt, was Sie geschrieben haben. Eines der Dinge, die mich wirklich stören, ist, dass viele Leute ihre VM sehr eng an ihre Ansicht gekoppelt zu haben scheinen - wenn Sie das tun, könnten Sie genauso gut einfach die alte XAML + alles, was in den Code dahinter eingefügt wurde Sache.

Das Muster, das ich verwende, ist eine leichte Variante des MVVM (aber es ist größtenteils dasselbe). Ich persönlich mag es, wenn mein ViewModel der View als Schnittstelle übergeben wird - so bleibt die Trennung sehr sauber. Dies hat viele Vorteile bei der Erstellung von Prototypen, da visuelle Elemente in oder aus der View mit wenig oder gar keinen Auswirkungen auf das ViewModel umgeschaltet werden können.

Answer 2

Ich denke, die Kommunikation zwischen View ViewModel über Datenbindung ist das, was MVVM zu einem eigenen Muster im Gegensatz zu anderen Trennungen macht. Es ist nicht so sehr, ob es, ob seine GUT oder SCHLECHT für die Vm über die Ansicht über Schnittstelle wissen, aber im Kontext der Kommunikation das Muster verwendet wird, ist es nicht MVVM.

Ein Teil der Schwierigkeit, Standards zu erhalten und zu pflegen, liegt leider in den Unzulänglichkeiten und der Komplexität von WPF und Silverlight. Wenn es jedoch mehrere gültige Standards gibt, würde ich meinen Martin Fowler-Hut aufsetzen und einen Abschnitt "wann man sie verwenden sollte" hinzufügen.

Decken Ihre Standards übergreifende Aspekte wie die Lokalisierung ab?

FWIW Ich mag den Inhalt dessen, was Sie geschrieben haben und bin froh, dass Sie es hier gepostet haben...

Zum Wohl,
Berryl