Frage zum Designkonzept MVVM unter Delphi

[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. Für mich gibt es (u.a.) zwei Sichtweisen die sich teilweise wiedersprechen.

1. Das Viewmodel abstrahiert die Daten und die Darstellung. Die View soll jederzeit austauschbar sein.
Beispiel: Es gibt ein Passwort und die Aktion Verbinden. Eine Logik besagt: die Aktion Verbinden darf nur ausgeführt werden, wenn das Passwort da ist.

2. Das Viewmodel repräsentiert die View, diese soll möglichst keine Logik enthalten.
Beispiel wie oben: Die Logik besagt: der Button für Verbinden ist nur Enabled, wenn in der Eingabe ein Text drin steht.

Bei 1 geht es eher um eine abstrakte Sichtweise, dagegen hat 2 eher die UI im Blick.

Anderes Beispiel:
Im Model hatten wir vier Auswahlmöglichkeiten. Es ging um die Plazierung einer gewissen Zone bezüglich der Oberfläche. Codiert ware das durch einen Aufzählungstyp.
Einerseits konnten wir das lösen mit einer IViewSelection im Viewmodel und in der UI einer Auswahlliste.
Andererseits war der Wunsch in der UI stattdessen vier Buttons zu haben (Radiobuttons waren auch eine Option)
Nach obiger Variante 2 würde man im Viewmodel dann vier IViewButtons machen und das Viewmodel schaut dass dann immer einer gedrückt ist.
Dagegen nach Variante 1 würde man bei der IViewSelection bleiben - es ist ja eine Auswahl - und dann in der UI die Logik implementieren.

Ich persönlich (und Stevie wphl auch) tendiere generell zu Variante 2. Da kann man mehr unit testen.

Zitat von Schokohase:

Ich habe mir schon so das ein oder andere zum Thema MVVM und Delphi angesehen. Dabei ging die Bandbreite von „lächerlich“ bis zu „ganz niedlich“ verglichen mit WPF, UWP, Xamarin.Forms mal als Referenz für „sehr brauchbar“.

Oder kennt jemand eine Delphi-Variante die sich mit der Referenz ansatzweise messen könnte?

Unsere
Betonung liegt allerdings auf "ansatzweise"

[Rollo62]

Zitat:

1. Das Viewmodel abstrahiert die Daten und die Darstellung.

Die Frage ist welche Logik ?

Ich denke das ViewModel dürfte/sollte sich auch um Animationen, Farbumschläge, evtl. Enabling/Disabling der Controls kümmern.

Aber da kommt man u.U. doch manchmel ungewollt der Business-Logik im Model in die Quere.

Für mich persönlich ist die View-Related Logik im ViewModel OK, und die
reine Business-Logik im Model (z.B. Datenbank, etc.).

Ich denke es gibt da keine generelle Super-Regel, denn sonst kämen ja nicht so viele Fragen dazu auf.
Muss halt jeder ein bischen so machen wie er das für Richtig hält.

Der gute Wille zählt

Rollo

[Schokohase]

Zitat von Rollo62:

Ich denke das ViewModel dürfte/sollte sich auch um Animationen, Farbumschläge, evtl. Enabling/Disabling der Controls kümmern.

Nein, das ist definitiv nicht die Aufgabe des ViewModels. Das ist einer der Punkte für die Trennung zwischen View und ViewModel.

• Das ViewModel stellt die Informationen zur Verfügung, was dargestellt werden soll.
• Die View kümmert sich darum wie das Was dargestellt werden soll (animiert, in rot oder blau, mit Kringeln oder Krapfen, ...)

[QuickAndDirty]

Für mich WÄRE MVVM wenn man die DFM-Dateien austauschen könnte, aber die Units der Formulare weiternutzen kann.

Ich werde zumindest nie wieder in Delphi Bindings benutzen. Habe damit nur schlechte Erfahrungen gemacht und muss auch sagen das sich die Delphi Bindings unfertig und unhandlich anfühlen.

Ohne Bindings kann es eigentlich kein MVVM geben.

Einige alternativen, die mir hier damals genant wurden , würde ich den Delphibindings vorziehen:

-Binding per Namenskonvention und Erweitertem-RTTI.
-Binding per Attribute

Beide methoden sehen mehr oder weniger vor, daß man sich ein kleines Framework baut welches verantwotrlich ist für
-das Binding
-das erzeugen und Freigeben von View und ViewModel
-das navigieren zwischen verschiedenen Views...und ihren Viewmodels

Das eine Projekt was ich als MVVM Projekt gestartet habe hat mittlerweile alle Bindings per code...und somit keinen MVVM character mehr.
Ich habe also ein Schicht Oberfläche und eine Schicht Geschäftlogik und dazwischen eine unnötige Schicht ViewModel die in beide richtungen nur noch weiterreicht und noch Navigation macht...
Sobald ich das Projekt auf Framestand umgestellt habe fliegen vermutlich viele dieser Zwischen Schicht klassen raus....

Im Moment ist MVP für mich das non plus ultra. Über ein Interface für Model und View definiert sich die interaktion ganz gut und die Presenter klasse stellt führt des Create den Gluecode für beide Interfaces aus und kann ansonnsten nichts!

[freimatz]

Bei uns sieht das Bindung z.B. so aus:

Delphi-Quellcode:

procedure TConstructGroupFrameEvalDirection.BindControls();
var
  evalDirection: IEvalDirectionViewModel;
begin
  ...
  //---- element id
  edDirElementId.Bindings.New(evalDirection.ElementId, BindingModeET.Bidirectional, true);
  //---- value
  vfDirection.Bindings.New(evalDirection.EvalDirection, BindingModeET.Bidirectional);
end;

Dabei sind edDirElementId und vfDirection Controls.

@Rollo: klar darf jeder machen was er will, nur soll er das dann nicht MVVM nennen.

Noch was: inzwischen sehen wir das MVVM zumindest für Delphi recht kritisch. Wenn wir von vorne anfangen müüsten würden wir das wohl nicht mehr verwenden.

[Schokohase]

Mir scheint als ob es hier beim Konzept noch Verständnisschwierigkeiten gibt.

Bei MVVM kommt es nicht darauf an, dass die View keinen Code enthält.
Die View darf allerdings nur Code enthalten für das Binding zwischen View und ViewModel und die Darstellung.

Beispiel:

Wenn der Spieler den HighScore genackt hat, dann sollen bunte Luftballons über den Schirm fliegen. Die View kümmert sich um die Luftballons und das fliegen. Die Information bzgl. des geknackten HighScores kommt aber aus dem ViewModel.

Wenn man eine View hat, wo "augescheinlich" gar kein Code vorhanden ist, dann sollte man etwas weiter hinter die Kulissen schauen und findet dort jede Menge Code (für das Binding oder die Darstellung). Je ausgefeilter das Präsentations-Framework umso weniger Code muss ich noch zusätzlich in die View schreiben (weil das ja schon jemand für mich gemacht hat).

Mit einem ganz vorzüglichen Framework braucht man tatsächlich nicht eine Zeile Code in der View zu tippen.

[Rollo62]

Zitat:

Die View darf allerdings nur Code enthalten für das Binding zwischen View und ViewModel und die Darstellung.

Aha siehe da. Genau das meine ich.

Und .. ich glaube vorsichtig zu meinen das man das nicht immer so sauber trennen kann.

Es ist wie mit OOP, theoretisch super, in der Praxis mag es mal hakeln.
(z.B. was heute Code deines Views ist, wird morgen womöglich Code deiner Business-Logik).

Rollo

[Schokohase]

Zitat von Rollo62:

Zitat:

Die View darf allerdings nur Code enthalten für das Binding zwischen View und ViewModel und die Darstellung.

Aha siehe da. Genau das meine ich.

Und .. ich glaube vorsichtig zu meinen das man das nicht immer so sauber trennen kann.

Es ist wie mit OOP, theoretisch super, in der Praxis mag es mal hakeln.
(z.B. was heute Code deines Views ist, wird morgen womöglich Code deiner Business-Logik).

Rollo

Eine gewagte These. Nenne mir ein konkretes Beispiel wo das zutrifft und ich werde dir den Fehler zeigen.

Fliegende Luftballons auf dem Bildschirm weil der Highscore genackt wurde haben nichts in der Logik zu suchen. Weder gestern, noch heute oder morgen.

[Rollo62]

Z.B. Verriegelung von Controls.
Ich darf Edit2 erst bearbeiten wenn in Edit1 etwas drinsteht.

Ja klar, du sagst das gehört nicht in das ViewModel, aber ich bin sicher es gibt Änderungen wo
dann erstmal solche Fälle erst egal sind, dann plötzlich in einem halben Jahr verlangt werden.

Ist das jetzt ViewModel oder Model Business-Logik ?

Sorry, hab gerade kein besseres Beispiel, bin im Stress ...

Rollo

[mkinzler]

Die Begrifflichkeit des MVVM wird tatsächlich in fast jeder Lösung verschieden interpretiert.
Mir gefällt der Ansatz von grijjy

Bin mit der Erweiterung allerdings noch nicht wirklich weit gekommen.

Würde mich aber um Mitstreiter freuen. (Gerne auch bessere Porogrammierer wie ich).