MVVM Framework für Delphi

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

[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

Delphi-Quellcode:

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

Delphi-Quellcode:

Sex

ist in

Delphi-Quellcode:

TDataPerson

und im DTO sagen wir mal vom Typ

Delphi-Quellcode:

Integer

.
Das ViewModel gibt aber diese Eigenschaft als Typ

Delphi-Quellcode:

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

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.

[Insider2004]

Das sind doch alles theoretische Betrachtungen, die mit der Praxis nicht vereinbar sind. UML ist so eine weitere Horrorstory. Das wird im Prinzip von niemanden in der professionellen Industrie angewendet.

[Daniel]

:stupid:
Das denke ich auch. Zudem wird Code ja auch schneller ausgeführt, wenn er gleich hinter dem Button hängt. Am Besten alles in einer Methode. Kann man ja mit GOTO hinreichend strukturieren.


Von eingeworfenem Spam mal abgesehen: Ich finde diese Diskussion rund um MVVM durchaus spannend, gerade Eure sachliche Schilderung von Anwendungsfällen, in denen es wirklich Sinn macht. Bitte weiter so.

[stahli]

Finde ich auch sehr gut. :thumb:

Wir hatten das Thema u.a. schon mal hier beim Wickel: http://www.delphipraxis.net/176478-m...realitaet.html
Und heute ist das schon fundierter.

Sir´s Erklärungen sind ja auch sehr einleuchtend.

Unter Delphi muss man natürlich einige Klimmzüge extra machen und selbst bei WPF gab es eine Lernkurve (notwendige Deklarationen in XAML oder unter BLEND), die man erst mal kennen und verstehen muss (und die mich erst mal abgeschreckt hat).
(Unter Delphi würde ich wohl in dem Fall nochmal nach DSharp schauen anstatt nach einer Lösung mit den LiveBindings.)


Vielleicht können wir die Frage aus dem anderen Thread nochmal aufgreifen:

Wer arbeitet ernsthaft mit MVVM (oder ähnlichen Patterns).
- Welches/was für ein Projekt?
- Welche Entwicklungsumgebung und Framework?
- Team oder Einzel-Entwickler?

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1286774)

Wer arbeitet ernsthaft mit MVVM (oder ähnlichen Patterns).
- Welches/was für ein Projekt?
- Welche Entwicklungsumgebung und Framework?
- Team oder Einzel-Entwickler?

Ich...
Umbau einer Fibu von VCL-D2007-non Unicode auf FMX-XE7-Unicode Win/OSX/iOS
XE7 - und was man so braucht programmiert. (:coder: in progress)
Eigentlich eine "one man Show"... Aber mit versierter Unterstützung (Danke!)

Mavarik

[Thomas_K]

MVVM mit DSharp hört sich vielversprechend an, eigentlich genau das was mir vorschwebt, doch wenn ich versuche das MVVM Demo Calculator Projekt zu kompilieren erhalte ich nur folgende Fehlermeldung

Code:

[dcc32 Fehler] DSharp.PresentationModel.EventAggregator.pas(345): E2003 Undeklarierter Bezeichner: 'IsGenericTypeDefinition'
[dcc32 Fehler] DSharp.PresentationModel.EventAggregator.pas(345): E2015 Operator ist auf diesen Operandentyp nicht anwendbar
[dcc32 Fehler] DSharp.PresentationModel.EventAggregator.pas(410): E2003 Undeklarierter Bezeichner: 'TryConvert'
[dcc32 Fataler Fehler] DSharp.PresentationModel.Coroutine.pas(11): F2063 Verwendete Unit 'DSharp.PresentationModel.EventAggregator.pas' kann nicht compiliert werden

Es wird im TRttiInterfaceType versucht auf IsGenericTypeDefinition zuzugreifen, was aber nicht existiert, ebenso gibt es keine TryConvert Methode in TValue.

Weis jemand mit welchen Stand bzw. Version von Delphi, Spring4D, DSharp, VirtualTreeView, ... es funktionieren könnte?