Frage zum Designkonzept MVVM unter Delphi

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

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