Frage zum Designkonzept MVVM unter Delphi

[Schokohase]

@Rollo62

Control.Enabled setzen macht die View, das Ermitteln wann und warum (z.B. erst wenn ein gültiges Land ausgewählt wurde kann man die Postleitzahl eintragen) ist Aufagbe des ViewModels.

Ob das ViewModel diese Aufgabe dann an das Model weiterdelegiert oder nicht ... was kümmert es die View. Das ViewModel sollte einfach eine Antwort darauf haben, damit die View ihre Arbeit erledigen kann.

Wenn es Änderungen an den Anforderugen gibt ... kommt darauf an was für Änderungen

• Statt fliegender Luftballons jetzt tanzende Mäuse? Betrifft nur die View.
• Zusätzlich zum Land müssen auch 3 Checkboxen gewählt sein? Betrifft nur das ViewModel (wenn es diese Eigesnchaften schon gab)
• ...

[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