MVVM Framework für Delphi

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