MVVM Framework für Delphi

[Mavarik]

Zitat von stahli:

Die ViewModels sind letztlich Wraper auf die Daten. Das Binding zwischen GUI und ViewModels wird über die LiveBindings durchgeführt.
Dann könnte man doch auch die GUI direkt über die LB an die Daten binden?

Ja diesen Gedankenfehler habe ich am Anfang auch gemacht...

Das Viewmodel ist die unabhängig BL der View um es mal einfach zu formulieren.
Eine View kann aber durchaus verschiedene ViewModels haben...

Und der Vorteil ist... Du kannst Das ViewModel mit UnitTests ausstatten bzw. testen, ohne die View überhaupt schon designt zu haben.

Mavarik

[stahli]

@Mavarik

Die Videos taugen aber nicht als sinnvolle Beispiele für MVVM.


@all

Die Diskussion gefällt mir und die genannten Gründe sind auch gut nachvollziehbar.

Aber die zu erzielenden Vorteile lassen sich evtl. auch leichter erreichen.

1) Vererbung DataObject zu BusinessObject

Ich habe in einem Framework einfache Datenobjekte deklariert. Z.B.

TDataPerson class
- Firstname
- Lastname
- Sex

und davon Businessobjekte abgeleitet

TPerson class(TDataPerson)
- FullName
- SexColorForGUI
- DataIsValid
- DoSomething(WithParam: Integer)

So habe ich klare Datenobjekte und kann die mit Eigenschaften für die BL und GUI erweitern.
Im Rahmen meiner Anwendungen hat das wunderbar funktioniert. Die Klassen selbst wurden durch das Framework erzeugt und das Framework konnte sich auch selbstständig um das Laden und Speichern der Daten sowie um die Bindung an die GUI kümmern.

Der MVVM-Ansatz soll ja das gleiche erreichen. Ok, er ist noch flexibler aber auch sehr viel aufwendiger.
[NACHTRAG: Das Binding zur GUI ist ja durch ein ViewModel in Delphi noch nicht gelöst. Das kommt ja als Aufwand sogar noch hinzu. Daher setze ich lieber auf ein Paket, das mir diesen gesamten Aufwand abnimmt.]


2) Komplett-Objekt

Grundsätzlich würde ich es auch nicht gänzlich ablehnen, Daten, Klassenlogik und GuiStatusinformationen direkt in einem Objekt unterzubringen.

Das obige Beispiel würde dann so aussehen:

TPerson class
[Data]
- Firstname
- Lastname
- Sex
[BL]
- FullName
- DataIsValid
- DoSomething(WithParam: Integer)
[GUI]
- SexColorForGUI

Das würde Delphi natürlich so nicht hergeben, aber mal als grundsätzliche Überlegung:
Man könnte Daten definieren, die von überall erreichbar sind und persistiert werden können.
Dann gäbe es Eigenschaften, die von der Buinesslogik und von der GUI aus erreichbar wären.
Und es gäbe Eigenschaften, die nur für GUI relevant und erreichbar wären.

Man müsste so nicht alles doppelt schreiben und hätte dennoch gentrennte Bereiche für verschiedene Aufgaben.



-> Also wie gesagt, die Ziele des MVVM erkenne und vertrete ich. Ich hätte aber ganz gern einen leichteren Weg dorthin.

[Sir Rufo]

@stahli

Dann hast du das mit dem MVVM aber nicht richtig erkannt

Das ViewModel wird nie niemals nicht vom Daten-Objekt abgeleitet, sondern das ViewModel kapselt das Daten-Objekt.

Code:

TDataPerson class
+ Firstname
+ Lastname
+ Sex

TPersonViewModel class
- DataPerson
- DataPersonDTO
+ Firstname
+ Lastname
+ Sex

Das ViewModel bekommt bei der Erzeugung eine Instanz von TDataPerson mit auf den Weg.
Dann nimmt das ViewModel diese Instanz auseinander (mit einem Assembler) und bekommt eine DTO-Instanz. Auf diese DTO-Instanz verweisen dann die Getter/Setter des ViewModels.

Speziell die Eigenschaft Sex ist in TDataPerson und im DTO sagen wir mal vom Typ Integer .
Das ViewModel gibt aber diese Eigenschaft als Typ TSexViewModel heraus, worüber dann nicht einfach nur der Wert, sondern auch alle möglichen Werte geholt werden können. Schon hat man alles an der Hand, um z.B. ein ComboBox komplett zu bestücken.

Erst dann macht das mit dem MVVM Sinn und Spass.

[stahli]

@Thomas_K

Dann solltest Du nochmal DSharp genauer anschauen...


@Sir

Das hatte ich schon richtig verstanden.
Ich denke nur, dass es einfacher wäre, von dem Datenobjekt abzuleiten, als dieses zu wrappen - also dass der MVVM-Ansatz im Sinne von Aufwand und Nutzen nicht der optimalste ist.

Aber dabei muss man auch immer sehen, dass ich von einer Fabrik ausgehe, die mir
- die Klassen erzeugt (der ich dann die BL noch hinzufügen kann)
- die Objekte instanziiert
- die Daten speichert und lädt
- die Bindung zwischen GUI und BL abwickelt.

Du hast schon recht, wenn Du diese Aspekte nicht willst, ist der MVVM-Ansatz schon in Ordnung (außer dass dann in Delphi immer noch die LiveBindings notwendig werden).

Ich scheue aber den Aufwand und will lieber ein Rundum-Sorglos-Paket, das mir den ganzen Kram abnimmt. So brauche ich nur noch die Datenstruktur festlegen, etwas Logik schreiben, ein paar Controls auf die Formulare ziehen und den Rest das Framework machen lassen.

Übrigens, auch in WPF war ich nicht so recht überzeugt von MVVM. Obwohl dort ja das Binding schon fest in der Entwicklungsumgebung integriert ist erscheint mir das sehr umständlich und anfällig (keine Namensprüfung zur Entwicklungszeit).

[Sir Rufo]

Ja, wenn man mit MVVM arbeiten will, dann muss man es nicht einfach sondern richtig machen. Wenn man sich da erstmal durchgebissen hat, dann werden nachträgliche Änderungen richtig einfach.

Es geht ja wohl auch nicht darum, dass jeder nun MVVM machen muss, aber wenn man damit anfängt, dann richtig oder gar nicht.

Und dass es keine Namesprüfung bei der Entwicklung gibt halte ich eher für einen Vor- als einen Nachteil.
Änderungen müssen ja im gesamten System stattfinden, allerdings aufgrund der losen Bindung können die View-Programmierer das Feld schon einbauen, auch wenn es das noch gar nicht gibt.
Der ViewModel Bauer führt dann im ViewModel die Eigenschaft ein und kann auch zunächst einen Dummy-Wert übertragen, bis die Model-Bauer die Daten zur Verfügung stellen können.
Hat man jetzt noch schöne Unittests, dann kann ein jeder seine eigene Schicht testen und am Schluss fügt sich alles hübsch zusammen.

Wer noch niemals einen Unittest geschrieben hat, nur alleine arbeitet, keine grossen Änderungen im System umsetzen muss, der braucht kein MVVM. Alle anderen wünschen sich einen anderen Weg und werden mit MVVM glücklicher. Die Lernkurve ist allerdings recht steil und Delphi hat da auch nicht die notwendigen Basics an Bord. Dadurch wird es nochmals schwieriger.

[Stevie]

Zu dem von Thomas_K oben verlinkten Video kann ich noch das hier empfehlen.

Für den Skillsprint von Nick zu MVVM muss ich mich eigentlich fast entschuldigen, denn er hat es leider einfach nicht richtig verstanden (die, die letztes Jahr bei der EKON in Nicks Vortrag dazu waren, haben meine Kritik daran auch live mitbekommen )

Ich hab vor, dieses Jahr die Arbeit am MVVM Framework wieder aufzunehmen (ob unter DSharp oder Spring4D wird sich dann zeigen).
Wer interessiert ist, daran mitzuwirken, kann mich gern kontaktieren.

[Thomas_K]

Hier wurde Aufwand von MVVM gesprochen, doch genau das ist ja der springende Punkt eines Frameworks, den Aufwand zu minimieren. Ein interessanter Ansatz ist dabei „Konvention vor Konfiguration“ das man sich hier für .net hier Rob Eisenberg Build Your Own MVVM Framework an(ab)schauen kann. Also konkrete bedeutet es das ViewModel bindet sich automatisch an ein View, in Abhängigkeit von Komponentenbezeichner im View und Eigenschaften/Methodennamen im ViewModel, so etwas für Delphi wer schon etwas.