Frage zum Designkonzept MVVM unter Delphi

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

[jus]

Vielen Dank für die vielen Anregungen.

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

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?

[Schokohase]

Zitat von jus:

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?

Lies bitte

Zitat von Stevie:

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

Du kannst gerne ohne Binding versuchen (da kann ich dir versprechen, das macht keinen Spaß) oder so wie Stevie, der ein eigenes Binding auf die Beine gestellt hat und ernsthaft (einer der ganz wenigen die ich kenne) MVVM nach Delphi bringen wollte - und der hat das Handtuch geworfen.

Wenn du dein Geld normalerweise zu einer Domina trägst, dann würde ich sagen, mach es und du sparst dir das Geld dort ein. Ansonsten folge dem Rat von Stevie: Vergiss es einfach.

[freimatz]

Zitat von Schokohase:

Du kannst gerne ohne Binding versuchen (da kann ich dir versprechen, das macht keinen Spaß) oder so wie Stevie, der ein eigenes Binding auf die Beine gestellt hat und ernsthaft (einer der ganz wenigen die ich kenne) MVVM nach Delphi bringen wollte - und der hat das Handtuch geworfen.
...
Ansonsten folge dem Rat von Stevie: Vergiss es einfach.

Ich finde es schon gut wenn man sich mit MVVM beschäftigt - auch mit Delphi. Das gilt aber eher zur Weiterbildung und nicht für produktiven Einsatz.

Wie schon geschrieben verwenden wir MVVM, würden es aber vermutlich wegen dem hohen Aufwand nicht mehr anfangen. Jetzt sind wir schon drin und machen dann damit halt weiter. Ich meine auch dass wir es "eichtig" machen. Allerdings ist für jede Klasse von Controls in der UI, die verwendet werden wollen, etliches an Zusatzcode notwendig um das Binding zu ermöglichen. Da wir aber nur eine begrenzete Menge an verschiedenen Controls verwenden ist das nicht so schlimm.

[TigerLilly]

Ich habe dieses Video

https://www.youtube.com/watch?v=virHepvMetw

sehr bereichernd und - für mich - praktisch nutzbar gefunden.

[Stevie]

Zitat von TigerLilly:

Ich habe dieses Video

https://www.youtube.com/watch?v=virHepvMetw

sehr bereichernd und - für mich - praktisch nutzbar gefunden.

Bei 11:36 hab ich schon beim ersten Mal als ich das letztes Jahr gesehen habe, den Kopf geschüttelt - da hat der gute Olaf glatt vergessen, dass die Reihenfolge hier einfach genauso ist wie bei MVC oder MVP

Ansonsten ist es bis zur Implementierung eins der besseren Videos aus der Delphi Welt über MVVM - allerdings stimme ich bei der gezeigten Implementierung dann doch dem Kommentar unter dem Video zu.

Bei 35:40 fängt der Blödsinn nämlich an und es wird Interaktionslogik in die View geschrieben. Die Interaktion der Eingabe mit dem Daten holen gehört in das ViewModel. Bei MVVM geht jede Eingabe ins Edit per data binding in das ViewModel hinein und wenn ich den Knopf drücke wird ein Command aufgerufen. Das ViewModel nimmt dann die entsprechenden Daten, die aus der UI in es hineingeflossen sind und macht etwas damit. Danach liefert es eine Benachrichtigung, dass es neue Daten zum Anzeigen hat (meist auch über die entsprechende data binding funktionalität).

Das mag dem einen oder anderen wie Erbsenzählerei vorkommen, ist doch egal, hauptsache trennen - nein, man muss sich einfach immer vorstellen, ob man das ViewModel einfach so testen kann, indem man ihm einfach nur UI Inputs gibt. In der gezeigten Möglichkeit gibt es das nicht, ich kann dem VM nicht einfach sagen, ich hab hier in das Suchfeld das da eingegeben und dann die Suchen Aktion gestartet, mach was - denn wie diese beiden Dinge in Verbindung stehen, stand in der View!

Wenn man das schon mit RAD lösen möchte, dann würden Data aware Controls der Sache am nächsten kommen. Ins VM würde dann ein Dataset (ClientDataSet, FDMemTable oder was weiß ich), die kann man hervorragend an entsprechende TDBXXX Controls verbinden und hat bidirektionalen Datenfluss und Benachrichtigungen ohne LiveBindings.

Ob man das aber für jede Fitzeloberfläche, die man in seiner Anwendung hat, machen mag wo man doch bei anderen Sprachen, die MVVM etwas besser unterstützen, nur ne kleine Klasse schreiben muss anstatt sich öffzig Datenmodule mit allem Brimborium zu basteln, weiß ich nicht.

Im Übrigen halt ich auch in WPF oder Xamarin Forms MVVM für noch arg unhandlich. Erst in JS, wenn man das schön ins HTML einbetten kann, wie bei Knockout oder Aurelia, wirds interessant.

Wenn man sich nen vernünftigen vortrag zu MVVM anschauen möchte, dann empfehle ich, diese: https://www.youtube.com/watch?v=FWT-W72sy64 (sorry, kein Delphi und auch nicht grad MVVM 101)
Darin zeigt Rob Eisenberg (Author von mittlerweile einigen MVVM Frameworks), was man so an eigener Infrastruktur bauen kann und sollte, damit man vernünftig MVVM durchführen kann (das dürfte so aus seiner Caliburn.Micro Zeit sein, wenn ich mich recht erinner).

Wenn ich es richtig in Erinnerung hab, dann dürfte das hier ein ganz guter Einstieg in MVVM sein: https://www.youtube.com/watch?v=tKfpvs7ZIyo (sorry, auch kein Delphi, aber dafür sieht man, warum das mit XAML viel fluffiger funktioniert als mit LiveBindings oder ähnlichem, sorry kein RAD Drag&Drop Programmierung)

[Thomas Feichtner]

Hallo zusammen,

hier gibt es ein schönes Buch von John Kouraklis "MVVM in Delphi". Hier wird eine kleine Anwendung auf MVVM umgebaut.

Ebenso hat mir das YouTube von Olaf Monien gut gefallen MVVM Anwendungen in Delphi Programmieren mit und nicht gegen Delphi.

Da wir sehr viel datenbankgebundenen Komponenten arbeiten gefällt mir der Ansatz sehr gut.
Wichtig ist einfach die Trennung GUI und Business-Logik.

[Schokohase]

MVC, MVP und MVVM trennen alle GUI und Businesslogik. Nur diese Trennung alleine macht also noch kein MVVM - so sehr man es sich auch wünscht, denn die Trennung steht bei jedem Muster auf der Fahne.

Die Art und Weise der Trennung entscheidet was es wirklich ist (MVC, MVP oder MVVM).

[stahli]

Man muss m.E. festlegen, was man erreichen will:
- Trennung BL und GUI (aus meiner Sicht immer wichtig!)
- Testbarkeit von BL?
- Austauschbarkeit der GUI?
- Getrennte Teams für BL und GUI?


Aus meiner Sicht genügen die Punkte 1 und 2.
In dem Zusammenhang genügt mir ein Framework, das ein gutes Databinding ermöglicht.
Dazu müssen die Schichten der BL und GUI aufeinander abgestimmt sein und miteinander kommunizieren.
Die BL würde nur Klassen wie TPerson und TCar definieren, die in sich vollständig funktionsfähig sind.
Die GUI würde an Objekte und Listen gebunden werden, z.B.
Edit1.Caption -> Person.FirstName
ListBox1 -> Person.MyCars
Die Zuordnung würde im Designer erfolgen und der Entwickler dabei vom Framework unterstützt werden.
Programmieren möchte ich keine Databindings und schon gar keine Controller o.ä.
Vom Prinzip wäre die GUI vergleichbar mit DBControls, nur dass diese an normale Objekte gebunden werden.

Meinen ersten Ansatz hatte ich hier mal vorgestellt: https://www.delphipraxis.net/173360-...framework.html

Inzwischen arbeite ich an einem neuen Projekt mit ähnlicher Zielstellung.


Wenn man die letzten zwei Punkte erfüllen will ist MVVM sicherlich ein guter Ansatz und der höhere Aufwand dann wahrscheinlich auch in Kauf zu nehmen.


@Schokohase:
Hattest Du meine pm gesehen?