MVVM in der Realität

[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%

[Dejan Vu]

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen. Für Delphi würde ich das auch nicht einsetzen. Im Web-Bereich und bei WPF sieht das schon ganz anders aus.

Die Trennung von UI und BL kann man auch anders hinbekommen, da braucht's kein MVVM.

[Stevie]

Zitat von 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%

Mich würde mal nen grob skizziertes Demo interessieren und auch, was das Framework letztlich so macht.
Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ich seh nämlich zum Beispiel gerade nicht, wo man bei MVVM großartig mit RTTI Probleme bekommt.
Bissle Werte von a nach b schuffeln durch irgendwelche Databindings und das wars doch.

Zitat von Dejan Vu:

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen. Für Delphi würde ich das auch nicht einsetzen. Im Web-Bereich und bei WPF sieht das schon ganz anders aus.

Die Trennung von UI und BL kann man auch anders hinbekommen, da braucht's kein MVVM.

MVVM steht und fällt mit der Leichtigkeit, die Data bindings zu definieren - und selbst bei XAML kann das schonmal ziemlich komplex werden - LiveBindings sind für sowas z.B. nen ziemlicher Schuss in den Ofen.
Aber wenn man sich Angular, Knockout oder andere Vertreter anschaut, dann schaut das schon enorm schön aus, wie man seine Daten so in die entsprechenden Stellen bringen kann.

[Mavarik]

Zitat von Dejan Vu:

Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen.

Warum nicht? Was hat das mit einander zu tun... Mal abgesehen von VCL... VCL was war das gleich noch? Lass mich überlegen... Ach ja das alte Ding was nur für Windows ging... Bevor es FMX gab...

[Mavarik]

Zitat von Stevie:

Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ab wann ist den ein System / Framework ein "echtes" MVVM und wann nicht?