Frage zum Designkonzept MVVM unter Delphi

[jus]

Hallo,

ich beschäftige mit MVVM und komme da einfach nicht weiter. Und zwar würde ich gerne das folgende geniale Beispiel von Sir Rufo im Beitrag XE5: Probleme mit LiveBindings "CheckedState(Self)" weiter ausbauen, doch es scheitert bei mir bei den grundsätzlich Designfragen.

Zitat:

Zitat von Sir Rufo (Beitrag 1243195)

Zitat:

Zitat von Kralle (Beitrag 1243184)

Was mache ich falsch?

Du benutzt Livebindings :mrgreen:

Dafür nehme ich MVVM, das kann ich immer so hinbiegen wie ich möchte und bin nicht darauf angewiesen, ob Komponente X und Eigenschaft Y auch für Livebindings vorgesehen vorbereitet ist.

Delphi-Quellcode:

unit ViewFormMain;

interface

  uses
    Windows,
    Messages,
    SysUtils,
    Variants,
    Classes,
    Graphics,
    Controls,
    Forms,
    Dialogs,
    StdCtrls;

  type
    TViewModel = class
    private
      FValue    : Boolean;
      FOnUpdate : TNotifyEvent;
      procedure SetValue( const Value : Boolean );
    protected
      procedure DoUpdate;
    public
      property OnUpdate : TNotifyEvent read FOnUpdate write FOnUpdate;
      property Value    : Boolean read FValue write SetValue;
    end;

    TMainFormView = class( TForm )
      Edit1 : TEdit;         // OI: OnChange => ControlChange
      Edit2 : TEdit;         // OI: OnChange => ControlChange
      Edit3 : TEdit;         // OI: OnChange => ControlChange
      CheckBox1 : TCheckBox; // OI: OnClick => ControlChange
      procedure ControlChange( Sender : TObject );
      procedure FormShow( Sender : TObject );
    private
      FModelLoading : Boolean;
      FViewModel    : TViewModel;
    protected
      procedure DoLoadFromModel; virtual;
      procedure DoSaveToModel; virtual;
      procedure ViewModelUpdate( Sender : TObject );
    protected
      procedure LoadFromModel;
      procedure SaveToModel;
      procedure SyncWithModel;
    public
      procedure AfterConstruction; override;
      procedure BeforeDestruction; override;
      property ViewModel : TViewModel read FViewModel;
    end;

  var
    MainFormView : TMainFormView;

implementation

{$R *.dfm}
  { TForm1 }

  procedure TMainFormView.AfterConstruction;
    begin
      inherited;
      FViewModel          := TViewModel.Create;
      FViewModel.OnUpdate := ViewModelUpdate;
    end;

  procedure TMainFormView.BeforeDestruction;
    begin
      inherited;
      FViewModel.Free;
    end;

  procedure TMainFormView.ControlChange( Sender : TObject );
    begin
      SyncWithModel;
    end;

  procedure TMainFormView.DoLoadFromModel;
    begin
      // Binding Model => View
      CheckBox1.Checked := ViewModel.Value;
      Edit1.Enabled     := not ViewModel.Value;
      Edit2.Enabled     := not ViewModel.Value;
      Edit3.Enabled     := not ViewModel.Value;
    end;

  procedure TMainFormView.DoSaveToModel;
    begin
      // Binding View => Model
      ViewModel.Value := CheckBox1.Checked;
    end;

  procedure TMainFormView.FormShow( Sender : TObject );
    begin
      LoadFromModel;
    end;

  procedure TMainFormView.LoadFromModel;
    begin
      if FModelLoading
      then
        Exit;

      FModelLoading := True;
      try
        DoLoadFromModel;
      finally
        FModelLoading := False;
      end;
    end;

  procedure TMainFormView.SaveToModel;
    begin
      if FModelLoading
      then
        Exit;

      DoSaveToModel;
    end;

  procedure TMainFormView.SyncWithModel;
    begin
      SaveToModel;
      LoadFromModel;
    end;

  procedure TMainFormView.ViewModelUpdate( Sender : TObject );
    begin
      LoadFromModel;
    end;

  { TViewModel }

  procedure TViewModel.DoUpdate;
    begin
      if Assigned( OnUpdate )
      then
        OnUpdate( Self );
    end;

  procedure TViewModel.SetValue( const Value : Boolean );
    begin
      if Value = FValue
      then
        Exit;

      FValue := Value;
      DoUpdate;
    end;

end.

Und zwar würde mich brennend interessieren, wie man das obige Konzept um Buttons und einem VirtualStringTree erweitern kann. Sollten man z.B. das OnClick Event von einem Button direkt mit der "ControlChange" Funktion verdrahten oder im ViewModel eine seperate Funktion erstellen?

lg,
jus

[Lemmy]

ist eigentlich ganz einfach:
was macht ControlChange? Es soll das Model/den Inhalt der Oberfläche aktualisieren.

Frage: Was soll beim Click auf den Button passieren? das selbe? Dann klar, mit der Methode verbinden. Wenn es was anderes machen soll, dann eben mit einer anderen Methode...

Vielleicht wird es mit einer Gegenfrage deutlicher: Du hast nicht nur einen Button, sondern 2. Soll jetzt bei einem Click auf einen der beiden Buttons immer das selbe passieren oder unterschiedliche Sachen? :-)

[jus]

Hallo Lemmy,
prinzipiell war meine erste Überlegung auch, dass ich einfach eine neue ViewModel-Methode erstelle. Um die kommt man vermutlich eh nicht rum. Was ich meine ist aber, dass das geniale an Sir Rufos Code ist, dass er die ganzen OnChange Events in ControlChange zusammenfaßt hat und die dann zentral auswertet. Ich versuche es kurz mal mit Code zu erklären. Und zwar weiß ich nicht, ob ich bei einem Button entweder sowas mache wie:

Delphi-Quellcode:

unit ViewFormMain;

interface
//...

  type
    TViewModel = class
    private
      FValue : Boolean;
      FOnUpdate : TNotifyEvent;
      procedure SetValue( const Value : Boolean );
    protected
      procedure DoUpdate;
    public
      procedure Button1Click;
      property OnUpdate : TNotifyEvent read FOnUpdate write FOnUpdate;
      property Value : Boolean read FValue write SetValue;
    end;

//...
implementation
//...


procedure TMainFormView.Button1Click(Sender: TObject);
begin
  ViewModel.Button1Click;
end;

 procedure TViewModel.Button1Click;
    begin
      //tue irgendwas
      showmessage('Mach Beep!');
    end;

Oder auch den OnClick Event vom Button1 direkt mit ControlChange verdrahte, und dann erst später die Verzweigung zu TViewModel.Button1Click mache, und zwar ungefähr so:

Delphi-Quellcode:

unit ViewFormMain;

interface
//...

  type
    TViewModel = class
    private
      FValue : Boolean;
      FOnUpdate : TNotifyEvent;
      procedure SetValue( const Value : Boolean );
    protected
      procedure DoUpdate;
    public
      procedure Button1Click;
      property OnUpdate : TNotifyEvent read FOnUpdate write FOnUpdate;
      property Value : Boolean read FValue write SetValue;
    end;

//...
implementation
//...

  procedure TMainFormView.DoSaveToModel( Sender : TObject );
    begin
      // Binding View => Model
      ViewModel.Value := CheckBox1.Checked;
      if (Sender as TComponent).Name = 'Button1' then ViewModel.Button1Click;
    end;



 procedure TViewModel.Button1Click;
    begin
      //tue irgendwas
      showmessage('Mach Beep!');
    end;

Hmmm... da weiss ich halt nicht wie Sir Rufo das gelöst hätte? :gruebel: :gruebel: :gruebel:

[freimatz]

Zitat:

Zitat von jus (Beitrag 1413773)

Hallo Lemmy,
prinzipiell war meine erste Überlegung auch, dass ich einfach eine neue ViewModel-Methode erstelle. Um die kommt man vermutlich eh nicht rum. Was ich meine ist aber, dass das geniale an Sir Rufos Code ist, dass er die ganzen OnChange Events in ControlChange zusammenfaßt hat und die dann zentral auswertet.
[...]
Hmmm... da weiss ich halt nicht wie Sir Rufo das gelöst hätte? :gruebel: :gruebel: :gruebel:

Ist das wichtig? Es ist doch dein code:wink:
Für zwei Aktionen die was verschiedenes machen brauchst Du nun mal auch im viewmodel zwei Dinge. Das könnte auch eine Methode mit einem Parameter sein. Oder zwei Klassen.

Auch wenn es dir nicht weiter hilft: Wir haben uns was selbst gestrickt und da erfolgt in so einem Fall das Binding von je einem Button auf je ein ViewCommand-Object im ViewModel.

[Lemmy]

Zitat:

Zitat von jus (Beitrag 1413773)

Oder auch den OnClick Event vom Button1 direkt mit ControlChange verdrahte, und dann erst später die Verzweigung zu TViewModel.Button1Click mache, und zwar ungefähr so:

ich führ dein Beispiel mal fort..

Delphi-Quellcode:

  procedure TMainFormView.DoSaveToModel( Sender : TObject );
    begin
      // Binding View => Model
      ViewModel.Value := CheckBox1.Checked;
      if (Sender as TComponent).Name = 'Button1' then ViewModel.Button1Click;
      if (Sender as TComponent).Name = 'Button2' then ViewModel.Button2Click;
      if (Sender as TComponent).Name = 'Button3' then ViewModel.Button3Click;
      if (Sender as TComponent).Name = 'Button4' then ViewModel.Button4Click;
      if (Sender as TComponent).Name = 'Button5' then ViewModel.Button5Click;
      if (Sender as TComponent).Name = 'Button6' then ViewModel.Button6Click;
....
      if (Sender as TComponent).Name = 'Buttonn' then ViewModel.ButtonnClick;
 
    end;

Das willst Du machen? Echt? :shock: DoSaveToModel hat eine Aufgabe: Daten von der Gui in die Objekte zu speichern, aber sicher nicht zu schauen ob der Sender einen bestimmten Namen trägt um dann irgend was zu tun...

Zitat:

Zitat von freimatz (Beitrag 1413781)

Ist das wichtig? Es ist doch dein code:wink:

ne, ist er nicht. Das ist der Code von dem Typ der nach ihm den Code warten muss. Wäre schön, wenn man immer wieder mal daran denkt... ;-)

[freimatz]

Vielleicht wäre auch mal wichtig die Frage zu stellen: was willst Du mit MVVM erreichen? Entkoppelung? Testbarkeit? Views austauschen? Oder?
Je nach dem kann das Design anders aussehen.

[Rollo62]

Bin nicht sicher ob ich deine Frage richtig verstehe.
Aber ich denke das ViewModel ist ein Abbild des Views, und die Load/Save Routinen speichern das nur entsprechend ab zur Synchronisation der Beiden.

Delphi-Quellcode:

procedure TMainFormView.DoLoadFromModel;
begin
      // Binding Model => View
      CheckBox1.Checked := ViewModel.CheckBox1Checked;
      Edit1.Text        := ViewModel.Edit1Text;
      Edit2.Text        := ViewModel.Edit2Text;
      Edit3.Text        := ViewModel.Edit2Text;
end;

...

procedure TMainFormView.DoSaveToModel;
begin
      // Binding View => Model
      ViewModel.CheckBox1Checked := CheckBox1.Checked;
      ViewModel.Edit1Text        := Edit1.Text;
      ViewModel.Edit2Text        := Edit2.Text;
      ViewModel.Edit3Text        := Edit3.Text;
end;

so das die ganze Logik im Model ist, und nicht mehr im View.
Jeder Zugriff in die Logik passiert dann ausschliesslich über das Model.

Rollo

[Stevie]

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

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

[freimatz]

Zitat:

Zitat von Stevie (Beitrag 1413803)

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:

Zitat von Schokohase (Beitrag 1413813)

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 :stupid:

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413828)

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:

Zitat von Rollo62 (Beitrag 1413842)

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

Delphi-Quellcode:

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

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1413816)

Zitat:

Zitat von Stevie (Beitrag 1413803)

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:

Zitat von Stevie (Beitrag 1413856)

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 :stupid:

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413860)

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 :stupid:

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 :shock:

Rollo

[Stevie]

Zitat:

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

Fixed :stupid:

[freimatz]

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

Zitat:

Zitat von Rollo62 (Beitrag 1413869)

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. :wink:

[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 :stupid:

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 :thumb:

Rollo

[Schokohase]

Schau dir mal in Ruhe die Beispiel-Anwendung an.

Nochmal, wenn du Fragen hast, dann stelle diese bitte konkret und nicht so nebulös wie "bei Desktop müsste ich evtl. noch die Netzwerk-Domain angeben" oder "bei WebSite muss ich womöglich einen Server auswählen".

Darauf kann ich nur antworten: "Evtl. müsstest du ...". Wenn du noch nicht weißt was du programmieren musst, wie willst du es dann programmieren? Aber evtl. beantwortet der AuthenticationService deine Frage.

Diese reine Lehre von MVVM passt eigentlich auf einen Bierdeckel. Also leg mal deine Ehrfurcht vor MVVM ab und schau dir an was es ist. Es sagt dir eigentlich nur: Trenne die bunten Lichter von den Fakten und den Faktenfindern.

Die Frage "Warum macht man MVVM?" kann man nur im Kontext beantworten.

Kontext Delphi (VCL, FMX): Macht man nicht (es sein denn man hat ganz viel Langeweile und keine Angst davor wen es doch nicht klappt)
Kontext WPF, UWP, Xamarin, ...: Weil diese Frameworks direkt auf MVVM zugeschnitten wurden.

[Rollo62]

Ich schau mir das Beispiel noch an, habe ich ja geschrieben ...

Das MVVM auf einen Bierdeckel passt glaube ich auch nicht.

Ich will weder ketzterisch noch ehrfürchtig klingen, anscheinend versteht man mich nicht ganz.
Nur denke ich MVVM hat wie Alles in der Welt mehrere Seiten, und man sollte nicht unbedingt immer Bibelartig dran halten.

Das Beispiel unten war genau das, nicht etwa das ich nicht definieren kann was mein Projekt können soll.
Meistens definiert das PROJEKT was ich machen muss (mein Kunde, geänderte Infrastruktur, Apple/Google/MS Updates, etc.), so dass solche Fragen wie unten sicher auftauchen.

Konkreteres Beispiel:
Ich habe eine App mit speziellem Login für EINEN User gleichzeitig.
Der Kunde verlangt nach einem Jahr das sich, weil MEHRERE User gleichzeitig den Rechner teilen, sich mehrere User gleichzeitig anmelden und arbeiten können.
Wo wird da was wohin gelegt, und wie ist die Transition von Version 1 zu Version 2 im produktiven Betrieb ?
Hat das MVVM für einen User noch viel mit dem MVVM für mehrere User zu tun ?
Was muss ich mit dem BusinessModel machen ?
Dinge können sich eben verändern.

Was wäre denn die Antwort darauf ?
Meine wäre bei Anforderungsänderungen rigoros reworken, auch wenns weh tun kann.

Ich will Sir Rufos Lösung nicht verteidigen, aber es ist auch EINE mögliche Implementiereng: Why not ?

Jetzt höre ich aber lieber auf damit, denn das bringt uns ja nicht weiter.

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Ich schau mir das Beispiel noch an, habe ich ja geschrieben ...

Das MVVM auf einen Bierdeckel passt glaube ich auch nicht.

Ich habe dir doch MVVM mit einem Satz erklärt, der passt auf einen Bierdeckel.

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Ich will weder ketzterisch noch ehrfürchtig klingen, anscheinend versteht man mich nicht ganz.
Nur denke ich MVVM hat wie Alles in der Welt mehrere Seiten, und man sollte nicht unbedingt immer Bibelartig dran halten.

MVVM sagt einfach nur etwas über die Trennung (Bunte Lichter, Fakten, FaktenFinder) aus. Wenn du es nicht mehr trennst, dann ist es kein MVVM mehr.

Zitat:

Zitat von Rollo62 (Beitrag 1413895)

Konkreteres Beispiel:
Ich habe eine App mit speziellem Login für einen User.
Der Kunde verlangt nach einem Jahr das sich, weil mehrere USer den Rechner teilen, sich mehrere User gleichzeitig anmelden können.
Wo wird da was wohin gelegt, und wie ist die Transition von Version 1 zu Version 2 im produktiven Betrieb ?
Dinge können sich eben verändern.

Was wäre denn die Antwort darauf ?
Meine wäre bei Anforderungsänderungen rigoros reworken, auch wenns weh tun kann.

Das passiert bei MVVM auch. Aber eben schön getrennt voneinander (MVVM sei Dank).

1. AuthenticationService
   Anpassen/Erweitern des Interfaces um die neuen Anforderungen erfüllen zu können (z.B. wird jetzt Domain, Username, Password benötigt)
2. ViewModel
   Hinzufügen der Eigenschaft Domain und beim Login verwenden
3. View
   Ein zusätzliches Edit-Feld einfügen und mit der Domain-Eigenschaft vom ViewModel binden

Fertig

[Rollo62]

Zitat:

Das passiert bei MVVM auch. Aber eben schön getrennt voneinander (MVVM sei Dank).

AuthenticationService
Anpassen/Erweitern des Interfaces um die neuen Anforderungen erfüllen zu können (z.B. wird jetzt Domain, Username, Password benötigt)
ViewModel
Hinzufügen der Eigenschaft Domain und beim Login verwenden
View
Ein zusätzliches Edit-Feld einfügen und mit der Domain-Eigenschaft vom ViewModel binden

Du vergisst aber das sich hier womöglich auch das BusinessModel ändern muss.
Also sind die Trennlinien M-V-VM schwimmend bei Anforderungsänderungen, und ich muss doch in Allen Teilen was anpassen.
Nach dem Motto "wie mans macht macht mans falsch".

Jetzt höre ich aber wirklich auf :stupid:

Rollo

[Schokohase]

Zitat:

Zitat von Rollo62 (Beitrag 1413897)

Also sind die Trennlinien M-V-VM schwimmend bei Anforderungsänderungen, und ich muss doch in Allen Teilen was anpassen.

Wieso sind die Trennungslinien schwimmend? Alles ist doch schön separiert voneinander und kann auch unabhängig voneinander erfolgen.

Aber wenn ich dem Anwender eine neue Information präsentieren will, dann hat das (oh welch ein unerwartetes Wunder) Auswirkungen auf alle Bereiche.

Die View muss es anzeigen, das ViewModel stellt es für die View zur Verfügung, das Model (hier z.B. der AuthenticationService) muss es beschaffen oder verarbeiten.

MVVM sagt nur: TRENNE DEINEN KRAM. Es ist nicht die Bibel oder die heilsbringende Lösung für alle deine Probleme.

[freimatz]

Amen. :-D

[Stevie]

Zitat:

Zitat von Schokohase (Beitrag 1413898)

MVVM sagt nur: TRENNE DEINEN KRAM.

MVVM spezifiziert schon recht genau, wie man den Kram trennt - nur weil man Kram trennt, macht man noch lang kein MVVM.

[Schokohase]

Zitat:

Zitat von Stevie (Beitrag 1414000)

Zitat:

Zitat von Schokohase (Beitrag 1413898)

MVVM sagt nur: TRENNE DEINEN KRAM.

MVVM spezifiziert schon recht genau, wie man den Kram trennt - nur weil man Kram trennt, macht man noch lang kein MVVM.

Ja, das habe ich ja auch weiter oben ausgeführt und hier nochmal auf eine verkürzte Aussage heruntergebrochen, weil immer noch zuviel in dieses MVVM hineininterpretiert wurde.

Ganz stark heruntergebrochen heißt MVVM: Trenne deinen Kram.
Ganz stark heruntergebrochen heißt ISO9000: Dokumentiere deinen Kram.

BTW:

Zitat:

Zitat von Stevie

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

Die Menge des Codes in der View entscheidet nicht ob MVVM-konform oder nicht, nur womit sich dieser Code befasst. Ist der Code rein auf die Kommunikation mit dem Benutzer beschränkt (bunte Lichter, Drag´Drop,...) dann ist das immer noch MVVM.

Ich lasse mich auch gern vom Gegenteil überzeigen anhand eines DragˋDrop Beispiels

[Stevie]

Ich zitiere mal Wikipedia (nicht weil Wikipedia immer recht hat, sondern weil das ein Kernpunkt von MVVM ist - wie ich auch bereits zuvor erwähnte. MVVM ohne Databinding ist kein MVVM).

Zitat:

Das MVVM-Muster kann als technologie-spezifisch bezeichnet werden, da für die Verknüpfung von View und ViewModel ein Datenbindungsmechanismus benötigt wird. Diese Infrastruktur wird häufig als Binder bezeichnet. Im Detail handelt es sich hierbei um einen bidirektionalen Einsatz des Beobachter-Musters. Binder, welche eine Datenbindung auf Basis von deklarativen Angaben etablieren können, sind für verschiedene Techniken vorhanden.

Und im Code aus Beitrag 1 und bei vielen anderen als MVVM bezeichneten Implementierungen sehe ich das nicht.
Ich poch da nur so drauf, weil es schon zu viele Delphi Entwickler gibt, die irgendwas MVVM nennen, was keins ist (oder was sie "für MVVM halten")

Zitat:

Zitat von Schokohase (Beitrag 1414002)

Ich lasse mich auch gern vom Gegenteil überzeigen anhand eines DragˋDrop Beispiels

Brauch ich nicht, hab schon gesagt, dass MVVM in Delphi imho Tinnef ist.

[jus]

Vielen Dank für die vielen Anregungen. :-)

Zitat:

Zitat von mkinzler (Beitrag 1413852)

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

Den Hinweis von mkinzler mit grijjy hätte ich mir auch gerne angeschaut, es ließ sich mit meiner alten Delphi 2007 Version nicht kompilieren.

Ich denke, dass ich zwar das Konzept von MVVM in Groben verstanden habe, aber vermutlich habe ich es nicht so gut verstanden, dass ich die konkrete Implementierung in Delphi hinbekomme. Ich würde mich halt viel einfacher tun, wenn ich eine einfache funktionierende Delphi Source hätte, wo ich mich halt weiterhanteln kann. Und nun meine ketzerische Frage, da wir bisher öfters schon gehört haben, was nicht MVVM ist. Kennt wer eine simple Delphi MMVM Beispielimplementierung mit Source, die ohne mächtiges Framework und Live-Binding auskommt? :duck: