MVVM in der Realität

[Patito]

Zitat von Union:

Scheint ja wohl daran zu liegen dass es noch keiner so wirklich nutzt.

Für mich ist MVVM eher etwas, das für kleine Projekte zu komplex ist, und für komplexe Projekte zu klein.
Als ich mein GUI-Framework geschrieben habe, habe ich zuerst mit Bindings experimentiert, bin dann aber
recht schnell Richtung MVP/MVC gegangen.

MVVM neigt einfach dazu das ViewModel komplett zu overengineeren. Mit MVP mit einem richtigen Controller statt
starrer Bindings ist man einfach flexibler.

Meine Praxiserfahrung: Eine Controller Klasse ist deutlich flexibler als ein Haufen starrer Bindings.
(z.B. kennt der Controller den View und kann nach einer Eingabe den Focus einfach auf ein passendes Feld setzen
- wenn man das über das ViewModel lösen muss, muss man sich erst mal Gedanken über Focus-Status Properties machen)

Wenn man es unbedingt braucht, kann man sich in den Controller dann immer noch ein paar starrere Bindings einbauen
(ich glaube Joanna Carter hat das damals "Interactor" genannt).

[Union]

Zitat von Patito:

Zitat von Union:

Scheint ja wohl daran zu liegen dass es noch keiner so wirklich nutzt.

Meine Praxiserfahrung: Eine Controller Klasse ist deutlich flexibler als ein Haufen starrer Bindings.
(z.B. kennt der Controller den View und kann nach einer Eingabe den Focus einfach auf ein passendes Feld setzen

Eben das sollte IMHO nicht direkt passieren. Ich würde da Passive View präferieren. Herangehensweise war ja auch die Austauschbarkeit des Views. Ich will doch im Presenter so was eben nicht haben:

FView.KundenEdit.SetFocus;

Oder habe ich Dich falsch verstanden?

[mquadrat]

Das was ich aktuell in der Mache habe, entspricht so ziemlich dem, was Union geschrieben hat. Wobei ich immer noch am Zweifeln bin, ob es nicht doch irgendwie machbar wäre unsere Legacy-Anwendungen mit DSharp zusammen zu bringen. Man braucht das Rad ja nicht krampfhaft neu zu erfinden.

@Patito
Der Vorteil von ViewModels ist vor allem die Tatsache, dass man die GUI weitgehend Unit-testen kann. Der Austausch der Views wird IMHO erst interessant, wenn man X-Plattform entwickelt. Bei allem was stärkeren Wert auf das Design legt als 0815-Delphi hat man noch den Vorteil, dass das ViewModel eine verlässliche Schnittstelle zwischen Frontend-Designer und Backend-Entwickler darstellt.
Aber MVP geht sicher auch. Das war ja auch das Pattern, dass Microsoft anfangs für .NET empfohlen hat. MVVM kam da ja auch erst später auf.

@stahli
Das kann man sicher mal machen, auch wenn ich nicht glaube, dass die Lösungen da sooo unterschiedlich ausfallen werden. Delphi-Entwickler sind nun mal eben eher traditionell. Dazu kommt, dass Emba MVVM nicht wirklich promotet. Ich wäre schon froh, wenn man beim uses .* nutzen könnte (oder hab ich das Feature etwa übersehen?)

[Patito]

Zitat von Union:

Eben das sollte IMHO nicht direkt passieren. Ich würde da Passive View präferieren. Herangehensweise war ja auch die Austauschbarkeit des Views. Ich will doch im Presenter so was eben nicht haben:

FView.KundenEdit.SetFocus; Oder habe ich Dich falsch verstanden?

Nunja, irgendwo muß dieses FView.KundenEdit.SetFocus ja rein. Es in einer abstrakten Form ins Model zu packen, ist eben oft recht seltsam. Ich bin aber auf jeden Fall auch dafür den View so passiv wie möglich zu halten.

Für die Austauschbarkeit der Views hatte ich von Anfang an immer eine Zwischenschicht drin, so dass der Presenter eben nicht direkt das Formular kennt, sondern eben nur das was der View ihm abstrahiert. Praktisch hat mir das aber eigentlich keinen Nutzen gebracht - und wenn ich nochmal von Null anfangen würde, würde ich darauf komplett verzichten.

Verschiedene Views brauchen (spätestens nach 5 Minuten im praktischen Einsatz) immer andere Models. Bei einem anderen View ist eben der Anwendungsfall immer leicht anders - dann braucht der Views vom Model bald auch leicht andere Daten, ... das driftet dann sehr schell auseinander.

Bleibt noch der Fall wo der View wirklich identisch ist (Plattformwechsel, Komponentensetwechsel).
- zur Plattformunabhängigkeit würde ich dann lieber gleich ein plattformübergreifendes Komponentenset nehmen (LCL).
- Wenn ich wirklich mal komplexe Komponenten gewechselt habe (verschiedene TreeView und Grids), habe ich mir "Interaktoren" als Abstraktionsschicht zwischen Presenter und Komponente geschrieben. Für den Presenter sehen dann z.B. in VirtualTreeView-Interactor und irgendein DevExpressTreeView-Interactor gleich aus (selbe Basisklasse).

[stahli]

Ich will das Thema nochmal hervorholen...

Bei Video2Brain ist ein Tutorial zu MVVM mit Prism unter WPF erschienen.
https://www.video2brain.com/de/video...mvvm-und-prism

WPF kann man ja sicher als das Paradebeispiel für MVVM ansehen, schließlich unterstützt es MVVM "nativ".
Wenn man dann noch ein Framework her nimmt, das nochmal alles vereinfachen soll (in dem Fall Prism), dann sollte alles easy und selbsterklärend funktionieren.

Das sehe ich aber überhaupt nicht.

Ich bin regelrecht erschrocken, was man dort alles regeln und beachten muss, damit man die eigene Anwendung in´s Laufen kriegt.

Sicher, machbar ist das, aber als Wunschlösung würde ich das nicht mal annähernd ansehen...

Wie seht Ihr das?


(Wer das Video nicht sehen kann oder will und Prim nicht selbst nutzt ist hier natürlich schon mal durch´s Raster gerutscht. )

[Sir Rufo]

MVVM hat Vorteile aber auch Nachteile. Damit muss man leben, wenn man damit hantieren will.

Warum nimmt man MVVM?

• Weil es fancy ist? - NEIN
• Weil man damit auf dicke Hose machen kann? - NEIN
• ...

MVVM ist speziell dafür gedacht, die Aufgaben der Programmierung zu teilen. Ein Team baut die GUI, ein anderes Team die BL und wiederum ein anderes Team den DAL.

Und damit das auch alles geteilt werden kann, hat man sich eben dieses MVVM ausgedacht.

Niemand hat gesagt, das MVVM Plug'n'Play ist, denn das ist es definitiv nicht. Es ist auch aufwändiger in der Implementierung. Dafür kann ich das Projekt aber aufteilen, die einzelnen Teile in sich testen und am Ende - wenn alle die Verträge eingehalten haben - alles zusammenführen und habe eine lauffähige Anwendung.

Spätere Änderungen können dann relativ einfach eingeführt werden, denn durch die strenge Entkoppelung wirken sich Änderungen in einer Schicht nicht unmittelbar auf eine andere Schicht aus. Jede Schicht kann ganz gemütlich für sich entwickelt und getestet werden.

WPF greift dem GUI-Team sehr stark unter die Arme, weil das Binding fast von selbst läuft, die anderen Teams haben davon gar nichts.

Insgesamt besteht eine Anwendung nachher nicht nur aus View-Model-ViewModel, sondern auch noch aus DTO (DataTransferObject), Services, ... (um nur ein paar Schlagworte zu verwenden.

[stahli]

Ok, das ist eine schöne und plausible Erklärung.

Für verschiedene Teams, die jeweils einzelne Projektteile bearbeiten, macht das Sinn. Das kann ich nachvollziehen.
Den Aufwand kann man dann auch verkraften und zieht insgesamt durchaus Vorteile.

Für Einzelentwickler ist das dann wahrscheinlich nicht unbedingt der sinnvollste Weg. Ich hatte das als "schöne neue Welt" angesehen (Plug&Play ist auch gut als Bezeichnung), die einfacher und bunter ist - aber das ist es dann halt doch nicht.

[Mavarik]

Zitat von Sir Rufo:

Warum nimmt man MVVM?

• Weil es fancy ist? - Ja
• Weil man damit auf dicke Hose machen kann? - Ja
• Weil diese Art der Programmierung mal wieder Spass macht... - JA!!!

Man(n) steht ja nicht morgens auf und überlegt sich - heute ist ein schöner Tag um mit MVVM zu beginnen...

Spätestens jedoch wenn man ein bisschen mehr Unit-Tests machen möchte, stellt man plötzlich fest - ohh doof ist ja im Formular...

Wenn man dann so vor sich hin programmiert, stellt man fest, dass die zeit bis zu einem Erflogreichen <F9> und man sieht etwas auf dem Bildschirm - deutlich länger ist... Als Clicky-Rad-Button-Coderein...

Aber die Möglichkeiten werden immer weitgehender... Und das macht einfach Spass...

Mavarik

[freimatz]

Zitat von Mavarik:

[*]Weil diese Art der Programmierung mal wieder Spass macht... - JA!!!

NEIN!!!

Wir setzen MVVM mit Delphi seit einien jahren ein. Das Framework ist selbst gemacht. Sehr aufwendig. RTTI mit Delphi ist ein Qual.
Anderen Nachteile wurden ja schon geannt, Vorteile auch.
Unschön finde ich auch, dass man die Logik im VM suchen muss, der Anteil leigt bei uns bei gefühlt 5%