MVVM in der Realität

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

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

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

[Stevie]

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

Wenn es nach den Merkmalen von MVVM (ich liste die nun nich auf, Google kann jeder selber bedienen ) funktioniert und nicht nur irgendnen GUI-von-BL-Trenn-Gerät ist. Genauso wie ich nich einfach irgendwo MVC oder MVP dran schreiben kann, nur weils die Benutzeroberfläche vom restlichen Code trennt.

Und es geht dabei nicht um ein Framework sondern um die Methodik.

[QuickAndDirty]

Ich bin ja was MVVM angeht absoluter Neuling und habe mir in der Sache hier auch schon mehrfach Rat geholt.
Mittlerweile viel gelesen und auprobiert....

Es gibt viele Fragen die man für eine MVVM Aufteilng seines Projekts nicht aus der Beschreibung des MVVM Patterns entnehmen kann. Auf Vieles musste man mich erst stoßen...bzw. es wurde mal so am Rande erwähnt und ich habe mir dann zu den Schlagwörtern was ergoogelt.
Vom MFP Pattern her kenne ich solche Probleme nicht und es kann am Ende das selbe wie MVVM. In größeren Projekten habe ich dann halt zum Teil einen Haufen an Interfaces.
Der große Unterschied ist wohl, dass ich mir durch die Livebindings die Interfaces aus dem MVP spare.

Mein bisheriger Wissensstand beim Versuch das MVVM Pattern zu nutzen:
1. Die Livebindings erfordern handgeschrieben code. Irgendwie finde ich das halbgar.
2. Das MVVM Pattern existiert innerhalb eines Frameworks, so richtig selbstständig ist es nicht. Ganz anders als MVP das ja ohne Framework auskommt.
3. Das Framework ist eine sehr wichtige Sache. "Make or Buy" ist zu klären, denn Delphi liefert es nicht wirklich mit.
4. Wenn man MVVM mit nur einer View macht funktioniert es super. Wenn man mehrere benutzen möchte ist nicht ersichtlich wie die Navigation zwischen Views ins Pattern passt. Es gibt hier 2 Philosophien ViewModel-First und View-First die entscheidend dafür sind wie man die Navigation löst. daran hängt ein Rattenschwanz von Entwurfmustern wie z.B. Inversion of Control und das verwenden von Frameworks die IoC-Container mitbringen. Ich habe mich für VM-first und eine convention-over-configurtion Ansatz entschieden, was die Navigation angeht. Sprich wenn ich zu einem neuen ViewModel navigiere, spawned das "Framework" die zugehörige View (getclass ftw.). Ich weiß nicht ob das "richtiges(TM)" MVVM ist, aber nach dem ich jetzt mehrere Views und ViewModel gemacht habe, fühlt sich der code echt gut an. Ich habe den Ansatz unter dem Stichwort "Autotview" in einem VS-c#-Forum gefunden.
5. Fehler !!1 MVVM und Ansätze die die RTTI stark in Anspruch nehmen scheinen mir gegenüber MVP anfälliger für Laufzeitfehler zu sein, weil die Abhängigkeiten nicht bereits zur Compilezeit geprüft werden können. Ich will ja eigentlich möglichst schon zur Compilezeit so viele Fehler wie möglich finden!

Gibt noch genug offene Fragen für mich...
Ich speichere z.B. zurzeit den Status der Anwendung in einem Session-Objekt welches ich dann persistiere, weil die Navigation auf VM-Ebene stattfindet und ich diese Informationen nicht umständlich von VM zu VM zu VM zu dessen Model-Object übertragen möchte. Mir gefällt das so, aber das Pattern sagt nichts dazu. Klar das Modelobject könnte ja auch für alle VMs das selbe sein. Das habe ich halt in die Session ausgelagert.

Ich nutze diesen thread einfach mal in der Hoffnung, dass mir jemand sagt ob ich soweit richtig liege.