Frage zum MVVM

Hi Leute,

ich hab mal ne Frage wie ihr das MVVM realisiert.

Also meine aktuelle Applikation programmiere ich so, dass ich fast alles ins ViewModel packe.
Ich hab mir nun darüber gedanken gemacht, ob ich nicht wieder einfache Dinge (Aktuelles Beispiel: Ein Button <Lösche alle Einträge> welcher eine Listbox leert) wieder direkt ins Codebehind des Views packe ?!?!

Im Moment besteht mein ViewModel nämlich aus der eigentlichen BusinessLogik, sowie der Logik zur Steuerung des Views, sprich meine Code-Behinds sind zu 95% leer.

Wie geht ihr da vor ?

Hi,

bin auch gerade dabei mich in das Thema einzuarbeiten.
Ich habe bis jetzt gar nichts mehr im Codebehind meiner Views, was, zumindest habe ich es so verstanden, auch das Ziel vom MVVM ist.
Dein Löschen-Button gehört meiner Meinung in das ViewModel, und sollte auch da bleiben...

Warum lagerst du nicht deine BusinessLogik noch weiter aus?

Viele Grüße
Jens

Nunja, für mich hört sich das nen bischen nach Verschlimmbessern an.

Ich finde im Eigentlichen, dass die View-Steuerung schon unmittelbar an den View gebunden werden sollte. Was habe ich von eine View-Steuerung, welche ich mit in meinem loggelöstem Modell (vom View losgelöst) rumschleppe ? Die kann ich dort eh nicht gebrauchen.
Ich könnt natürlich jetzt im ViewModel die Steuerung meines Views implementieren und in einem weiterem Teil (nennen wir es dann quasi BusinessModel) die Business-Logik implementieren.
Das ganze wäre jedoch nur eine Verschiebung von dem was ich anfangs vorgeschlagen hatte.

Im Endeffekt sollte man sich doch die Frage stelle, wohin so ein Löschbutton (um nochmals auf mein Beispiel zurückzukommen) nun letzendlich hingehört.

• zum Model gehört er auf keinen Fall, da er keine Datenstuktur etc. ist
• zum ViewModel gehört er meiner Meinung nach auch nicht, da er keine direkte Auswirkung auf irgendwelche (business)logischen Vorgänge hat, sondern nur indirekt durch seine Aktionen auf eine Liste wirkt, welche z. B. eine Collection steuert
• zum View gehört er, da er diesen (und letzendlich nur diesen) verändert. Er leert eine Liste, mehr tut er nicht

Natürlich ist klar, dass die Liste mit ihren Elementen maßgeblich an den Vorgängen im ViewModel beteiligt ist, daher ist sie auch direkt per Binding an dieses gebunden, der Button jedoch ist dem ViewModel gänzlich unbekannt und steht in keienrlei direktem Verbindung zu diesem, sein einziger Weg das ViewModel zu beinflussen geht über die Liste.

Also für mich klingt es deutschlicht strukturierter, wenn wir den Löschbutton, deshalb unmittelbar im CodeBehind an den View binden, oder ?

Hallo meisteralex ,

zum ViewModel gehört er meiner Meinung nach auch nicht, da er keine direkte Auswirkung auf irgendwelche (business)logischen Vorgänge hat, sondern nur indirekt durch seine Aktionen auf eine Liste wirkt, welche z. B. eine Collection steuert

Wenn der "Löschbutton" Items aus einer Collection entfernt hat das imho nichts mit der View zu tun und ist ganz klar Logik welche ins ViewModel gehört. Von daher würde ich die Logik des Buttons in ein Command auslagern und dieses and den Button binden (So wie es das MVVM-Pattern vorsieht).

Sprich, der eigentliche Button gehört zur View, die Logik die ausgeführt wird wenn der Button betätigt wird gehört ins ViewModel.

Schöne Grüße,

Tachyon

Moin zusammen,

also der Lösch-Button gehört natürlich in die View - ist halt GUI - aber die Aktion selber (sprich: der Command) muß meiner Meinung nach ins ViewModel. Ziel des Patterns ist ja u.a. auch die Möglichkeit das ViewModel ohne View zu testen...was schwierig wäre wenn Logik - wie das Löschen von Daten - nicht zur Verfügung stehen würde.

Ich würde auch ViewModel und Businesslogik nicht unbedingt gleichsetzen. Das ganze MVVM-Pattern ist für mich Präsentationsschicht, ein Zugriff auf die eigentliche Businesslogik erfolgt über eine separate Schnittstelle.

LG, Stefan

Das ganze MVVM-Pattern ist für mich Präsentationsschicht, ein Zugriff auf die eigentliche Businesslogik erfolgt über eine separate Schnittstelle.

Genau das ist auch mein Verständnis. Das ViewModel bildet eine Art "Wrapper" um das Model und die Businesslogik und bereitet die Daten / die Funktionalität soweit auf, dass die View damit umgehen kann.

Also seht ihr das ViewModel mehr als einen Adapter ?

Ich sehe das ViewModel mehr als eine "bindabare Logik".
Als ich angefangen habe, mich mit dem MVVM - Pattern zu beschäftigen, hat es mich vor allem begeistert, dass ich den View direkt an meine Logik binden konnte. Ich konnte die Listen mit denen ich auf logischer Ebene arbeitete direkt benutzen um meine Anzeige zu generieren.

Wenn ich das ViewModell jetzt wieder als einen "aufbereitenden" Adapter sehe, habe ich ja wieder das gleiche Speil, dass ich zwischen meiner Logik und dem ViewModel-Adapter eine Art Synchronität schaffen muss, was für mich wieder ein Schritt in die Gegenrichtung wäre.

@Blues: natürlich ist es Ziel des MVVM die Logik auch ohne den View testen zu können, jedoch müssen wir hier ganz genau zwischen ApplikationsLogik (BusinessLogik) und AnzeigeSteuerungsLogik differenzieren:

Um das deutlich zu machen können wir uns als Applikation z.B. einen Analysesoftware vorstellen, welche (hochkomplizierte g) Rechnungen und Auswertungen in der Businesslogik erstellt und diese letzendlich als Ausgangsform in einer Datatable oder Collection zur Verfügung stellt. Genau hier hört jedoch für mich die Logik der Businesslogik auf!
Das der View letzendlich aus der Tabelle mit ein paar Berechnungen einen Graph erzeugt, ist die Aufgabe der ViewLogik und nicht der BusinessLogik! Die Software lässt sich hierbei auch einwandfrei testen, ohne das wir die Funktionalität der Visualisierung brauchen, welche in der ViewLogik implementiert ist. Weitergehen könnten wir z.B. auch den kompletten View(+Logik) austauschen und der selbigen BusinessLogik einen View verpassen, welcher nicht mehr einen Graph darstellt, sondern die Daten in Form eines Grids in sortierbaren Spalten darstellt.

Ungefähr verständlich worauf ich hinaus will ?

Hi,

das ViewModel enthält nur die Logik, die der View braucht um die Daten aus dem Model(=Businesslogik) darzustellen. Dein Beispiel mit der Analysesoftware stimmt also. Die Businesslogik stellt Daten in einem beliebigen Format zur Verfügung. Diese Daten breitet das ViewModel für den entsprechenden View auf (z. B. verschachtelte Objekte auflösen, Daten zum Zeichnen eines Graphen aufbereiten). Der View bindet an die Daten des ViewModels und stellt sie graphisch dar.

Um auf den Löschbutton zu kommen: Der Button beeinflusst den View nicht direkt, sondern nur dessen ViewModel. Die ListBox ist an eine Collection im ViewModel gebunden, also muss der Button ein Command im ViewModel auslösen, das die Collection im ViewModel leert.

(Das ist zumindest wie ich MVVM verstanden habe. 😉)

Grüße,
Alex

Hallo zusammen,

um das noch einmal klar zu machen:

also der Lösch-Button gehört natürlich in die View

Ja - er gehört ins "View" (im herkömmlichen Sinne).
Allerdings wird dieses "View" mithilfe von MVVM durch ein Model ein ViewModel und ein weiteres View, für das es leider keinen anderen Namen gibt, ersetzt.
MVVM ist also sozusagen ein View-internes Pattern.

Ich würde auch ViewModel und Businesslogik nicht unbedingt gleichsetzen.

Unter keinen Umständen sollte man das Gleichsetzten!