Frage zum Designkonzept MVVM unter Delphi

[Stevie]

Zitat von freimatz:

Zitat von Stevie:

Brrrr, das ist doch kein MVVM, was Sir Rufo da geschrieben hat. Viel zu viel Code in der View.

Das kommt drauf an, was man unter MVVM versteht.

Das ist leider so oft das Problem, dass manche nur ein Buzzword nehmen und dann was komplett anderes unter diesem Namen bauen oder verstehen.

ViewModel heißt genau so, weil es das Model für die View ist. Es stellt die Logik dar die in der UI vonstatten geht, damit man
- diese ohne UI Geklicke testen kann
- jemand, der geile UIs baut, das machen kann, ohne sich um Code zu kümmern (in Delphi nur bedingt möglich)
- man die UI je nach Zielplatform austauschen kann, ohne die Logik und Interaktion neu zu bauen (nur bedingt möglich, je nach Platform verhält sich die UI zu unterschiedlich, als dass man VMs wiederverwenden könnte)

Ein Kernaspekt von MVVM ist das binding zwischen UI/View und ViewModel und entsprechende Benachrichtigungsmechanismen. Das sollte man eigtl schon verstehen, wenn man sich nur das Bild auf Wikipedia anschaut. Wenn man anfängt statt dessen Code in die UI zu schreiben, die Bindings und Notifications zu ersetzen, dann ist das nunmal kein MVVM.

Und ja, die Jungs von Grijjy haben das verstanden - allerdings steht und fällt MVVM nutzen in Delphi mit der Komplexität und dem Tooling. Ein XAML, was mit direkt beim Kompilieren den Finger zeigt, weil ich was falsches gebunden habe ist weitaus hilfreicher als irgendwelche AVs oder sonstwas zu suchen, weil ich nen vertippser oder so im LiveBinding (oder einer anderen stringly typed Implementierung) habe.

Ich persönlich hab inzwischen das Thema MVVM in Delphi ad acta gelegt, weils einfach nicht rund wird. Für kleine Spielzeug Anwendungen ganz toll aber unbrauchbar, wenns größer wird.

[Schokohase]

Zitat von Stevie:

Ich persönlich hab inzwischen das Thema MVVM in Delphi ad acta gelegt, weils einfach nicht rund wird. Für kleine Spielzeug Anwendungen ganz toll aber unbrauchbar, wenns größer wird.

Den gesamten Beitrag unterschreibe ich so wie er ist. Aber den zitierten fett hervorgehobenen Satz darf man sich aktuell getrost in den Bildschirm ritzen. Bis sich das (bei Delphi) ändert wird der Monitor schon in Walhalla sein.

[Rollo62]

Zitat:

Ob das ViewModel diese Aufgabe dann an das Model weiterdelegiert oder nicht

Ja, um die View geht es nicht.
Aber wo ist denn jetzt diese Verriegelung richtig aufgehoben ?
Da kommen sicher oft die Philosophen ins Spiel

Rollo

[Schokohase]

Zitat von Rollo62:

Zitat:

Ob das ViewModel diese Aufgabe dann an das Model weiterdelegiert oder nicht

Ja, um die View geht es nicht.
Aber wo ist denn jetzt diese Verriegelung richtig aufgehoben ?
Da kommen sicher oft die Philosophen ins Spiel

Rollo

Wenn du die Frage philosophisch stellst ...

Stell sie konkret, dann gibt es auch eine konkrete Antwort.

Die Verriegelung selber passiert in der View, denn nur die hat Zugriff auf das Control.
Das ViewModel hat eine Eigenschaft, die den Verriegelungs-Status reflektiert, den die View dann nimmt um die Verriegelung am Control zu setzen.
Wo dieser Status jetzt konkret ermittelt wird hängt davon ab, was konkret da dargestellt werden soll.

• Soll verriegelt sein, wenn der User wo auch immer angemeldet ist? Dann fragt man dazu den entsprechenden Service (also Model).
• Soll verriegelt sein, wenn ein anderes Feld im ViewModel noch nicht bestückt ist? Dann kann das das ViewModel entscheiden.
• Soll verriegelt sein, wenn ein anderes Feld im ViewModel noch nicht korrekt bestückt ist? Dann kann das das ViewModel mit Hilfe eines Service entscheiden ... (irgendwo liegt ja dei Definition was ist korrekt)

[Rollo62]

Ich sehe das weniger philosophisch, eher konzeptionell und praktisch:

ViewModel reflektiert View --> d.h. eigentlich ist das Alles zusammen "View-Stuff"
Der "View-Stuff" ist die View mit ViewModel eng verschweisst.
Model ist die Kapselung der Business-Stuff.

Soweit, so gut

Der "View-Stuff" sollte IMHO möglichst ein automatisches Binding ohne Programmierung bekommen,
ich glaube hier hakt es beim Delphi-Rad Ansatz am meisten.

Das ViewModel ist der "Controller" (in Ermangelung eines besseren Ausdrucks) für die View,
ist aber deshalb sehr eng mit der View verbunden, wenn nicht sogar 1:! reflektiert.

Das ViewModel kann ich separat Testen: Hier fängt der entscheidende Vorteil an ...

Jetzt habe ich aber in meinem Projekt
"View-Stuff Desktop"
"View-Stuff Mobile"
"View-Stuff WebSite"
etc.

idealerweise brauche ich dafür nur EIN ViewModel nehmen, in der Praxis funktioniert wohl eher nicht.

Dann gibt es ein BusinessModel, welches soll mit
"View-Stuff Desktop"
"View-Stuff Mobile"
"View-Stuff WebSite"

in gleicher Weise interagieren soll.

Wie bekomme ich denn die unterschiedlichen ViewModel immer ans eine BusinessModel geschraubt ?
(Wohlgemerkt ich rede hier mal von realen Anwendungsfällen, nicht die "Hallo Welt" Standard-Adress-Eingabe).

Ich bemühe mich immer das möglichst zu generalisieren, aber leider spielt die reale Welt nicht immer mit.
Wahrscheinlich bin ich zu blöd für das perfekte MVVM

Rollo

[Stevie]

Zitat:

Wahrscheinlich ist Delphi zu blöd für das perfekte MVVM

Fixed

[freimatz]

Sehe ich nicht so, es fehlt halt das passende brauchbare FrameWork.

Zitat von Rollo62:

Ich sehe das weniger philosophisch, eher konzeptionell und praktisch:

ViewModel reflektiert View --> d.h. eigentlich ist das Alles zusammen "View-Stuff"
Der "View-Stuff" ist die View mit ViewModel eng verschweisst.
Model ist die Kapselung der Business-Stuff.

Du darfst das so sehen, aber bitte nenne das nicht MVVM. Danke.

[Schokohase]

Also zu jeder View gibt es ein ViewModel.

Wenn die Desktop-View und Mobile-View gleich sind, dann ist auch das ViewModel gleich.
Wenn nicht ...

Der Business-Layer besteht idR aus Services, die dem ViewModel per Konstruktor-DI übergeben werden. Hier bietet sich somit auch ein DI-Container an. Also es wird nicht das ViewModel an das Model übergeben, sondern das Model an das ViewModel.

Update
Wer sich dafür interessiert kann sich ja mal ein echtes Beispiel anschauen, wo MVVM verwendet wurde. Da kann man sehr viel von lernen.

SmartHotel360 - Connect(); 2017 keynote demo apps

Und hier als Beispiel das LoginViewModel und die zugehörige LoginView (CodeBehind) (da sehen wir minimalen Code ... aber der ist nur für die Anzeige)

[jus]

Hallo,
ich gebe zu dass in dem Beispiel von Sir Rufo kein Model vorhanden ist, aber ich denke, das zu erweitern ist nich so schwer.
Aber wie würdet ihr das Beispiel ändern, damit es MVVM konform wird?

[Rollo62]

Zitat:

Du darfst das so sehen, aber bitte nenne das nicht MVVM. Danke.

Was genau war an der Beschreibung denn so falsch ?

@Schokohase
Ja endlich mal ein richtiges Projekt, leider finde ich da unter Delphi kaum etwas.
Leider bin ich ungerne auf C# und Java, aber da gibt es natürlich mehr reale Projekte,
ich werde mir deinen Link morgen etwas tiefer anschauen.

Aber nehmen wir daraus nur mal Z.B. den LoginView:
- bei Mobile as is
- bei Desktop müsste ich evtl. noch die Netzwerk-Domain angeben
- bei WebSite muss ich womöglich einen Server auswählen

Also wären M- und D-View unterschiedlich, dementsprechend M- und D-ViewModel unterschiedlich.
Oder kann man ein Basis-ViewModel für alle Fälle definieren, und nur Ableitungen in M- D- W- bilden ?
Müssten dann etwa auch die BusinessModels unterschiedlich sein ?
Oder sollte das BusinessModel Alle Fälle unterstützen und die VieModels federn das ab ?

Ja es ist schon spät und das ist vielleicht etwas an der Haaren herbeigezogen,
aber das wäre meine grundsätzliche Fragestellung zu dem Ganzen Thema.
Was sagt denn die reine Lehre dazu ?

Ich sehe eben Fälle wo die reine Lehre an ihre Grenzen stoßen kann, und kann mich dann damit auch zufrieden geben.
Statt die 99% Perfekt auf 100% zu hieven, reichen mir manchmal eben 95% (3-Sigma) auch noch aus

Wäre nett da mal was Konkretes zu lesen, wie vom Schokohasen, und nicht nur das Übliche "ich würde das nicht MVVM nennen" abzuspulen.
Ich kann es auch "n-Tier Model-View" oder "Otto" nennen, und lasse das Ganze MVP, MVVM, MVC, M* Gedöns mal aussen vor.

Es geht doch immer um Erreichung gewisser Ziele, die manchmal diametral gegeneinanderstehen.
Modularisierung, Entkopplung, Testbarkeit, Codequalität, Lesbarkeit, Lernkurve, Automatisierbarkeit, Teamarbeit, Komplexität, Redundanz, Flexibilität, Time-to-Market, LOC, Kompatibilität, etc. etc. etc.
Keiner macht MVVM nur weil es so sagenhaft cool ist.

Zitat:

Aber wie würdet ihr das Beispiel ändern, damit es MVVM konform wird?

Ich denke MVVM und der ganze M* Kram sind nicht in Stein gemeisselt, sondern können durchaus diverse Implementierungen haben.
Mir gefällt die Lösung unten auch nicht besonders, aber Sir Rufo ist da sicher auch kein Anfänger.
Diese Lösung greift gewisse Ziele auf und löst diese, aber eben nicht Alle (sofern das überhaupt geht).

Da ist mir Delphi eine pefekte, saubere Lösung leider immer noch schuldig geblieben.
Alle die finden das ich hier Quatsch rede können mich gerne Überzeugen und eines Besseren belehren

Rollo