Ich bevorzuge grundsätzlich Lösungen mit Databinding, die ohne Controller oder Presenter auskommen.
Dazu müssen Controls halt in der Lage sein, vorhandene Datenstrukturen zu erkennen und die
GUI daraufhin anzupassen.
Eine ListBox wird also an die Autoliste des Fuhrparks gebunden und ein Edit an die Eigenschaft Lastname des Fahrer(objekt)s.
Ich möchte für die Verbindungen einfach keinen Code schreiben müssen.
Natürlich müssen dafür die Controls selbst wissen, wie sie mit der Datenschicht kommunizieren können.
Und wo implementierst du, dass man einen Fahrer mit nur Führerschein Klasse B nicht in den 12-Tonner setzen kann?
Es kommt ein bisschen darauf an, ob die Datenhaltung im ViewModel oder im Model ist.
Hier findet man oft sehr unterschiedliche Ansätze..
Nach dem Motto : Das ViewModel hat nur die Status- und Steuerungslogik die Daten liegen immer im Model...
oder
Das Viewmodel hält zusätzlich die Daten der View und das Model ist nur für eine Datenbank-Schicht da.
Ich habe bereits beide Ansätze versucht und verwende es so wie es optimal für die Aufgabe ist.
Ob man den "Aufwand" triebt für ein Fenster, dass keine "Daten" benötigt ist die andere Frage...
Eigentlich ist es recht unmissverständlich definiert - siehe
https://msdn.microsoft.com/en-us/lib...8246.aspx#sec7
Die Frage ist eher, wie sehr man die Daten kapselt. Wenn jemand sagt, meine Daten sind in Form eines Datasets, dann kann man das natürlich argumentieren, dass das VM die einfach durchreicht.
Ob man damit allerdings eine gute Testbarkeit und Kapselung erreicht, stell ich mal in Frage.
Auch bestimmte Anforderungen beeinflussen, wie sehr das VM das M duplizieren muss. Es gibt zum Beispiel VM Basisimplementierungen, die das Edit/Save/Cancel implementieren und dann an das View bloß eine Kopie der Modelldaten binden und beim Save bzw Cancel die Änderungen zurück kopieren oder verwerfen.