MVVM Framework für Delphi

[mquadrat]

Hallo zusammen,

nachdem ich die letzten Wochen in WPF und C# unterwegs war, habe ich mir die Frage gestellt, ob es eigentlich ein brauchbares MVVM Framework für Delphi gibt?!


Vielen Dank im Voraus ;)

[Thomas_K]

Ich greife mal den Thread auf, da ich mehr oder minder dieselbe Frage erneut stelle.

Ich habe erste Versuche in MVC und MVVM ohne ein Framework zu verwenden unternommen, im Großen und Ganzen funktioniert es auch so wie gewünscht, nur die Komplexität des Quellcodes und damit der Aufwand ist aber nicht ohne. Für die einzelne Programmfunktionen wurden einzelne Controller bzw. ViewModels geschrieben, die wiederum einzelne Modele vorrausetzen. Man hat zum Schluss sehr viele einfache Klassen in sehr viele Dateien geschrieben. Ein Großteil des Quellcodes besteht nur darum sicherzustellen, dass die einzelnen Komponenten mit einander Daten/Informationen austauschen können, also der Anwender löst im View eine Aktion aus, die dem ViewModel mitgeteilt wird, das wieder dem Model weiterreicht und dann endlich eine Aktion ausführt und das Resultat wird dann wieder dieselbe Kette rückwärts bis in den View über mittelt. Beachten muss man das ViewModel und das Model selbst wieder aus vielen einzelnen Komponenten bestehen, die wiederum selbst Daten/Informationen untereinander austauschen müssen.

Das Ganze verlangsamt das Programmieren von relativ kleinen VCL bzw. FMX Anwendungen deutlich und macht das ganze nur bedingt praktikabel, nun bin ich auf der Suche nach Beispiele, die die Komplexität minimieren und bin dabei auf ein interessanten Mitschnittes eines Seminars gestoßen
Introduction to MVVM - The Delphi Way https://www.youtube.com/watch?v=dOXXtitTy3s In dem knapp einstündigen Mittschnitts wird u.a. ein VCL Beispiel unter Verwendung eines MVVM Framework besprochen. Dieses Framework verwendet Generics und die RTTI, so dass man relativ wenig Glue Code in seiner eigentlichen Anwendung schreiben muss. Was ich aus dem Video noch nicht entnommen konnte, ob der Beispiel Quellcode veröffentlich wird oder nicht bzw. wie man mit dem vortragenden Redner Kontakt aufnehmen kann.

Gibt es irgendwo ein Beispiel VCL/FMX, dass unter Verwendung eines Frameworks das MVVM Pattern (oder Artverwandte) umsetzt?

[Lemmy]

Hi,

hier vom Skill Sprint 19.8.2014:
https://www.youtube.com/watch?v=sGn3-CsCYYM

Build an MVVM App in Twenty Minutes with Nick Hodges

Code gibt es sicherlich irgend wo zum runter laden (kommt i.d.R. auf der letzten Folie)

Grüße

[stahli]

In die zwei Videos werde ich mal noch reinschauen...

Aber grundsätzlich finde ich MVVM in der Praxis (unnötig?) komplex.
Ich bin ja zu C# gewechselt und habe mir auch mal WPF+MVVM (incl. DevExpress) angesehen.
Es kann natürlich an mir liegen, aber ich bin damit nicht klar gekommen.
Es gibt aus meiner Sicht zu viele Abhängigkeiten der einzelnen Schichten.

Ich wünsche mir eigentlich eher ein direktes Binding wie es mit den LiveBindings angedacht war (die aber nicht wirklich einsetzbar sind).

Auch in DSharp erschien mir der MVVM- oder MVP-Ansatz (ich weiß nicht mehr genau) zu kompliziert. Jedenfalls konnte ich die Demo nicht nachvollziehen.

Ich hatte ja mal ein Binding-Framework angefangen: http://www.delphipraxis.net/173360-s...framework.html
Das ist natürlich nicht die Spitze der aktuellen möglichen Technologie, aber diese Arbeitsweise finde ich immer noch sinnvoll und wünschenswert.

Es lassen sich sehr leicht Businessobjekte definieren und die Bindung zur GUI lässt sich ebenso leicht herstellen.
Den Grundgedanken will ich daher noch nicht endgültig verwerfen.

MVVM will natürlich eine Trennung zwischen BL und GUI erreichen, was sinnvoll ist. Der Aufwand für den Programmierer ist aber im Allgemeinen sehr hoch um diese beiden Schichten und das Binding zu organisieren.

Ich würde mir eine Lösung wünschen, die einen extrem einfachen getrennten Aufbau von BL und GUI ermöglicht und die Bindung zwischen Controls und BL-Objekten im Sinne einer Verdrahtung realisiert.

PS: Der Beitrag kann auch gerne nach http://www.delphipraxis.net/160506-t...tellungen.html verschoben werden. ;-)

[Thomas_K]

@Lemmy
Danke für den Hinweis, Nick verwendet leider kein Framework - trotzdem sehr Intersannt.

@stahli
Bindings ist sicherlich ein sehr wichtiger Punkt und das hat mich in dem Introduction to MVVM - The Delphi Way aufhorchen lassen, es sind nur 3 Zeilen Code für 3 Bindungen!
Erklärt bzw. gezeigt wird in dem Video hier an dieser Stelle https://www.youtube.com/watch?v=dOXXtitTy3s#t=28m08s Die MVVM Demo Code Erklärung startet hier https://www.youtube.com/watch?v=dOXXtitTy3s#t=25m08s

Sinn eines Frameworks ist es mit möglichst wenig Programm Code aus zukommen und das wird hier wirklich gut im Video gezeigt. https://www.youtube.com/watch?v=dOXXtitTy3s#t=35m36s Eine Programmänderung erfordert nur Anpassungen des Quellcodes im ViewModel.

[DeddyH]

DSharp hast Du Dir bereits angeschaut?

[Lemmy]

Zitat:

Zitat von stahli (Beitrag 1286581)

Aber grundsätzlich finde ich MVVM in der Praxis (unnötig?) komplex.

schön, dass das jemand genauso sieht... :-)

Ich habe zwischen 2009 und 2010 in einem Projekt sehr massiv das MGM (Model Gui Mediator) Pattern eingesetzt, das fand ich einfach, schlank und einfach anzupassen... fertige frameworks mit umgesetzten fertigen MVVM habe ich bisher noch nicht angeschaut (in Delphi)

[Dejan Vu]

Bindings gibt es doch in MVVM. Man zieht nur eine Schicht rein, damit man die Businessobjekte von den visuellen Anforderungen trennen kann (Bereitstellung einer Lookup-Liste z.B.)

MVVM ist ähnlich überflüssig wie ein solides Architekturkonzept für ein Haus.

Deine Gartenlaube benötigt so etwas nicht, auch der Anbau am Seitenflügel deines Einfamilienhauses nicht. Auch ein Fertighauß kommt ohne Konzept aus.

Aber ein Hochhaus, oder gleich eine ganze Stadt, kommt ohne Architektur und sehr durchdachte Konzepte nicht aus, denn wenn Du die Kabelschächte vergessen hast, aber im Dachgeschoß doch Abwasser und Strom brauchst, siehst du sonst alt aus.

Ich würde persönlich einem RAD-Tool wie Delphi allerdings kein MVVM aufstülpen, obwohl das mittlerweile einigermaßen hinhaut: Jede IDE/Programmiersprache bzw. Framework hat seine Vorteile. Kann sein, das das toll funktioniert, aber das ist beinahe so, als ob man mit nem Mini Pakete ausfährt. Geht, aber der Mini wurde wegen des Parkplatzmangels in der City zugelegt. Zum Ausfahren nehme ich dann noch den Lieferwagen.

Gerade benötige ich einen Prototypen für eine Mobile-App und ärgere mich, daß ich kein Delphi rumzuliegen habe, mit dem das am schnellsten ginge.

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1286608)

[...] Gerade benötige ich einen Prototypen für eine Mobile-App und ärgere mich, daß ich kein Delphi rumzuliegen habe, mit dem das am schnellsten ginge.

Nimmt man für Prototypen nicht sowieso besser spezialisierte Tools wie Appcooker o.ä.?

[mquadrat]

MVVM in Delphi braucht halt sehr viel Disziplin. Aber der Vorteil ist bei Cross-Plattform-Entwicklung schon nicht zu verachten. Bis zum View-Model bleibt ja alles gleich; nur der konkrete View ist anders. Ebenso kann ich in einem Programm für einen Kunden einen anderen View einbauen, ohne dass mir irgendwas um die Ohren fliegt. Die Bindings zwischen View und View-Model werden ja in den meisten Frameworks sowieso über Konventionen erzeugt.

Wir arbeiten aber aktuell auch nicht mit MVVM, was wohl daran liegt, dass wir nur noch Legacy-Anwendungen in Delphi haben. Da ist die Stoßrichtung eher Evolution als Revolution ;)

[Mavarik]

Zitat:

Zitat von Lemmy (Beitrag 1286602)

Zitat:

Zitat von stahli (Beitrag 1286581)

Aber grundsätzlich finde ich MVVM in der Praxis (unnötig?) komplex.

schön, dass das jemand genauso sieht... :-)

Unnötig? hmm, sagen wir mal so:

Ich bin 30 Jahr
- ohne MVVM ausgekommen.
- ohne Unittests ausgekommen.
- ohne SVN oder vergleichbares ausgekommen.

Ich bin 20 Jahr ohne eine Datenbank ausgekommen..

Ich bin 10 Jahr ohne Handy ausgekommen (die gab es da noch nicht)
oder 25 Jahr ohne ein iPad...
uvm.

Über den Nutzen und die Komplexität eines Handys wollen wir sicherlich nicht diskutieren.

Aber:
- Ich nutze sein 10 Jahre eine Datenbank
- Ich programmiere für mobile Devices seit XE2
- Nutze TortoisHg seit knapp 1,5 Jahren
- Programmiere Unittest seit einem Jahr
- Ich habe mich, nachdem ich das Video von Nick gesehen habe, aufgerafft und programmiere im MVVM-Style

Und ich habe immer gesagt... "Wofür? Ich brauche das nicht..."

So schnell ändern sich die Sichtweisen.

Mavarik :coder:

[Lemmy]

Zitat:

Zitat von Mavarik (Beitrag 1286625)

Und ich habe immer gesagt... "Wofür? Ich brauche das nicht..."

das habe ich doch auch nicht behauptet. Nur dass ich MVVM gegenüber anderen (MVC, MVP, MGM, MVW,...) aufwändiger und geschwätziger finde. Andere haben auch hübsche Töchter :-)

[stahli]

Den praktischen Nutzen der obigen Video-Beispiele verstehe ich nicht wirklich.

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?

Sinnvoll wäre die Trennung, wenn unterschiedliche Views an die BL angebunden werden sollen. Aber das würden die LiveBindings ja auch schon nicht ermöglichen. Ok, man könnte später die Datenschicht leichter austauschen, aber das ist ja wohl nicht das Ziel der Beispiele.

Auf mich wirkt das irgendwie wie ein Selbstzweck, nur um ein MVVM vorzeigen zu können.

Die Arbeit erleichtert es sicher nicht. Und die Trennung von BL und GUI kann man auch leichter beibehalten.



Wie gesagt, ich bin Fan der Trennung von BL und GUI. Unbedingt.
Die Frage ist aber, wie einfach oder aufwendig man das erreicht und ob man das nutzt, um eine modulare und flexible Programmierung EINER geschlossenen Anwendung zu erreichen oder ob man verschiedene GUI´s unterschiedlicher Plattformen an eine BL binden will.

Im letzteren Fall muss man einen höheren Aufwand betreiben, aber wann braucht man das wirklich?
I.d.R. hat man doch seine Formulare und will die möglichst einfach an die BL binden, die irgendwo im Speicher liegt und ihren Kram erledigt.

Ich will die BL komfortabel coden, die GUI komfortabel RAD-mäßig zusammenbasteln und den Controls sagen, welche Daten sie anzeigen sollen (ähnlich wie DB-Controls der Feldname zugewiesen wurde). Das ist meine Wahnvorstellung... ;-)

Wenn man dann in der GUI keine BL-Logik unterbringt ist doch eigentlich alles super.

[Sir Rufo]

Das was in den Videos gezeigt wird ist einfach nur ein Witz und dient eher dazu alle von MVVM fern zu halten.

Aber warum zeigen die dann sowas?

Ganz einfach, für MVVM fehlen eine ganze Menge an Basisfunktionen, die man erst einmal implementieren muss. Wenn man dazu keine Lust hat, dann eben Finger davon lassen.

Wer MVVM verstehen will, der muss bei .net ein Auge werfen. Da gibt es jede Menge guter bis sehr guter Beispiele, was bei Delphi eher dürftig bis unausgegoren zu sehen ist.

Sehr schönes Beispiel ist die StateMachine, die inspiriert wurde vom Stateless Projekt. Bei .net eine tolle Implementierung wo jedes OOP-Herz höher schlägt. Und Delphi ... nein, das sage ich jetzt nicht, nur soviel, der Autor hat teilweise gar nicht verstanden worum es dabei geht. :roll:

[mquadrat]

@stahli

Im View-Model kannst du auch deine Geschäftsdaten für die Anzeige transformieren oder zum Beispiel abgeleitete Eigenschaften implementieren. Man bindet beim View-Model ja nicht nur die Daten, sondern auch Eigenschaften wie z.B. Enabled eines Buttons. Die Entscheidung ob ein bestimmter Button enabled sein soll oder nicht, gehört nicht wirklich in die Geschäftslogik - vor allem nicht, wenn man PODOs verwendet. Ist die Eigenschaft im View-Model kann ich sie mit einem Unit-Test überprüfen. Ich kann also im Unit-Test Verhalten der GUI testen.


@topic

Das Studium von MVVM.light oder Caliburn Micro (beides .NET) führt einem schon vor Augen warum das Sinn machen kann(!).

[Dejan Vu]

Zitat:

Zitat von stahli (Beitrag 1286645)

Die ViewModels sind letztlich Wrapper 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?

Wenn ich die gängigen Programmierpattern (OCP, SRP, SOC usw.) stringent umsetzen will, dann führt kein Weg an einem MVVM-ähnlichen Konzept vorbei. Die Frage ist, ob ich das will, oder ob ich nicht doch pragmatisch das nicht ganz umsetze und manchmal ein wenig schludere.

Je komplexer ein System ist und je höher die Anforderung an Änderungen ist, desto eher sollte man die o.g. Konzepte 100% umsetzen. Hat man dagegen ein relativ einfaches bzw. normal komplexes System mit einigen wenigen Installationen, kann man ruhig etwas hemdsärmeliger an die Sache rangehen.

Ich betreue derzeit ein Bankensystem mit zig Installationen, wo nicht *wir* die Änderungen vorgeben und in neuen Releases und Versionen verteilen, sondern der Kunde quasi pausenlos Änderungen und Erweiterungen fordert. Uns fallen genau die Codestellen mächtig auf die Füße, die eben hemdsärmelig umgesetzt sind. Und ich bin heilfroh, u.a. MVVM eingeführt zu haben, denn an diesen Stellen sind wir flexibel wir nur irgendwas. Alle Klassen, die der Lead-Developer ohne OCP und SRP gebaut hat ("die Klasse macht alles automatisch") sind jetzt schon unbrauchbar. Letztendlich kommen wir nur dann mit den limitierten Resourcen über die Runden, wenn wir am Anfang unsere Hausarbeiten (MVVM usw) gemacht haben bzw hätten.

Ein anderes Uralt-Projekt ist etwas grober gestrickt (20 Jahre alt) und dort geht vieles nicht bzw. nur mit Codeklimmzügen, die heute schon ein Ende der Lebensdauer des Projekts einläuten (nach 20 Jahren ist mir das langsam auch wurscht).

Mit MVVM (z.B.) mag es heute ein Krampf sein, aber da man gezwungen ist, alles total sauber zu trennen wird man sich morgen freuen. Man muss es nur durchziehen. Bis zum letzten Buchstaben.

Einer der Architekten meinte:"Heute wird ein (Zeit-)Kredit aufgenommen, der sich morgen aber doppelt und dreifach zurückzahlt".

[Lemmy]

Zitat:

Zitat von Sir Rufo (Beitrag 1286649)

Das was in den Videos gezeigt wird ist einfach nur ein Witz und dient eher dazu alle von MVVM fern zu halten.

das war auch mein erster Gedanke, als ich den Skill Sprint von Nick angeschaut habe

Zitat:

Zitat von mquadrat (Beitrag 1286657)

@stahli

Im View-Model kannst du auch deine Geschäftsdaten für die Anzeige transformieren oder zum Beispiel abgeleitete Eigenschaften implementieren. Man bindet beim View-Model ja nicht nur die Daten, sondern auch Eigenschaften wie z.B. Enabled eines Buttons. Die Entscheidung ob ein bestimmter Button enabled sein soll oder nicht, gehört nicht wirklich in die Geschäftslogik - vor allem nicht, wenn man PODOs verwendet. Ist die Eigenschaft im View-Model kann ich sie mit einem Unit-Test überprüfen. Ich kann also im Unit-Test Verhalten der GUI testen.

Das ist doch mal was :-) Bei meinem MGM das ich vor einigen Jahren eingesetzt habe, hatte ich genau das Problem: Ich musste das Businessmodell um Properties erweitern die nur dazu da waren die Oberfläche zu steuern. Das kam mir damals irgend wie nicht richtig vor...

Danke für eure Posts!

[Sir Rufo]

Zitat:

Zitat von mquadrat (Beitrag 1286657)

Im View-Model kannst du auch deine Geschäftsdaten für die Anzeige transformieren oder zum Beispiel abgeleitete Eigenschaften implementieren. Man bindet beim View-Model ja nicht nur die Daten, sondern auch Eigenschaften wie z.B. Enabled eines Buttons. Die Entscheidung ob ein bestimmter Button enabled sein soll oder nicht, gehört nicht wirklich in die Geschäftslogik - vor allem nicht, wenn man PODOs verwendet. Ist die Eigenschaft im View-Model kann ich sie mit einem Unit-Test überprüfen. Ich kann also im Unit-Test Verhalten der GUI testen.

Eigentlich hat man in einem ViewModel nicht den Enabled-Status eines Buttons drin, sondern für jede Aktion, die ausgeführt werden kann ein

Delphi-Quellcode:

CommandViewModel

mit den Minimal-Eigenschaften

• DisplayName
• Enabled

sowie einer Methode

Delphi-Quellcode:

Execute

. Den Button (besser eine Action nehmen und die an den Button) verknüpft man nun einfach mit diesem

Delphi-Quellcode:

CommandViewModel

und schon ist alles gesagt, was gesagt werden muss.

Weiterhin habe ich im ViewModel nicht nur die Möglichkeit der Daten-Transformation, sondern auch das Bereitstellen von Lookup-Listen.

Delphi-Quellcode:

TPersonViewModel = class( ... )
public
  // Benachrichtigung
  property PropertyChanged; // Multicast-Event
  // Lookup
  propery GenderList;
  // Daten-Felder 
  property Gender : Integer;
  property FirstName : string;
  property LastName : string;
end;

Das sind Sachen, die ich niemals in meinem Daten-Model haben möchte. Vor allem, weil das ViewModel sich auch um die Konsistenz-Prüfung kümmern kann, die darüber hinaus gehen, was das Daten-Modell prüfen kann/soll.

Wobei eine Daten-Instanz eher immutable (unveränderbar) sein sollte. Für das Auseinandernehmen und Zusammenbauen nimmt man einen Assembler und ein DTO (DataTransferObjekt). Das DTO hat jetzt die Möglichkeiten die Daten auf Konsistenz zu prüfen. Der Assembler baut aus dem DTO eine Daten-Instanz, wenn das DTO keine Fehler meldet. Das ViewModel nimmt eine Daten-Instanz mit dem Assembler auseinander in ein DTO und kann nun auch darin schreiben. Erst wenn das ViewModel und DTO keine Fehler mehr melden, dann gibt das ViewModel das Speichern-Kommando frei und baut mit dem Assembler eine neue Daten-Instanz zusammen, schickt diese an den Service, der sich um das Speichern kümmert. Konnte die Daten-Instanz erfolgreich vom Service gespeichert werden, schickt der Service eine Nachricht in die Runde, dass diese Daten-Instanz jetzt die aktuell gültige ist und alle ViewModels die es interessiert können diese jetzt übernehmen.

Und ja, das ist etwas ganz anderes als einfach einen Button ein Grid und eine Datenquelle auf ein Formular zu klatschen. Eigentlich bin ich doch schon fertig und geht auch viel schneller. Klar, wenn die Anwendung nur daraus besteht, ist ja auch alles gut, nur kenne ich wenige Anwendungen die damit auskommen. Da ist immer erheblich mehr und konsistent soll es auch sein. Und dann ist da noch der Multi-User-Fall. Da ändert ein anderer die Daten und nun, wie bringe ich meiner Anwendung bei diese Änderungen auch zu übernehmen?

Mit der oben skizzierten MVVM-Lösung wird der Service einfach dahingehend erweitert, dass er diese Änderung auch von aussen bekommt. Die Verteilung nach innen ist ja schon fertig :)

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1286645)

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.

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

[Sir Rufo]

Auch wenn ich Stevie da jetzt auf die Füsse trete, aber für mich ist weder DSharp noch Spring4D wirklich einsetzbar, da dieses nicht auf den ARC Plattformen komplett funktioniert.

Eigentlich schade, denn gerade bei Spring4D sind viele der Basics schon implementiert, die man für MVVM dringend benötigt - aber wenn man es nicht benutzen kann, was bringt es dann.

Zu DSharp hat Stevie aber schon gesagt, dass er das in der nächsten Zeit wieder anfassen möchte und auch aktive Mitstreiter herzlich willkommen sind.

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen :mrgreen:

[mkinzler]

Zitat:

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen

Und wenn nicht, schubse ich Dich gern ;)

[Lemmy]

Zitat:

Zitat von Sir Rufo (Beitrag 1286817)

Zu DSharp hat Stevie aber schon gesagt, dass er das in der nächsten Zeit wieder anfassen möchte und auch aktive Mitstreiter herzlich willkommen sind.

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen :mrgreen:

Danke...

Zitat:

Zitat von mkinzler (Beitrag 1286818)

Zitat:

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen

Und wenn nicht, schubse ich Dich gern ;)

Da helfe ich auch gerne.. also beim Schubsen... :-)

[Stevie]

Hab grad eine Änderung in DSharp/develop gepushed, die es dir ermöglichen sollte, das Calculator Demo zu kompilieren (getestet mit Spring4D 1.0 und 1.1).

Virtual Treeview wird für das Projekt jetzt nicht benötigt, aber ich glaub der hängt über den TVP zumindest irgendwo im MVVM Code - läuft aber auch mit der aktuellsten Version.

In DSharp/feature/spring4d-compatibility ist der MVVM Teil noch nicht umgestellt worden, daher funktionierts dort nicht.

Wie schon gesagt, die Arbeit am MVVM Teil liegt seit einer Weile aus Zeitmangel und anderer Prioritäten (Spring4D, TestInsight) etwas brach.

Zitat:

Zitat von Sir Rufo (Beitrag 1286817)

Auch wenn ich Stevie da jetzt auf die Füsse trete, aber für mich ist weder DSharp noch Spring4D wirklich einsetzbar, da dieses nicht auf den ARC Plattformen komplett funktioniert.

Da und da kannst du mir/uns gerne auf die Füße treten, solang du willst - "funzt nicht" ignorier ich aber generell. :)

Gerade bei Spring4D haben wir extra einen Entwickler, der alle Features auf Mobile testet und auch einsetzt.

[Thomas_K]

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Gerade für die Mobile-Entwicklung will ich auf MVVM setzten, was für in System/Prinzip benutzt ihr in euren Apps?

[Stevie]

Zitat:

Zitat von Thomas_K (Beitrag 1286832)

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Packages kannste die für XE6 nehmen und umbenennen. Zeilenumbruch wird am git eol handling liegen, hab da noch keine .gitattribute Datei reingepackt.

[Insider2004]

Zitat:

Zitat von Thomas_K (Beitrag 1286832)

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Gerade für die Mobile-Entwicklung will ich auf MVVM setzten, was für in System/Prinzip benutzt ihr in euren Apps?

Weil die XML-Norm Unix definiert.

[Daniel]

Hast Du dafür eine Quelle?

[mkinzler]

Stevie hat schon den Grund genannt. Aber der Insider hat da natürlich mehr Einblick.

Sogar mehr als die Autoren von XML!

Zitat:

Zitat von http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-formed

2.11 End-of-Line Handling

XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating all of the following to a single #xA character:

the two-character sequence #xD #xA

the two-character sequence #xD #x85

the single character #x85

the single character #x2028

any #xD character that is not immediately followed by #xA or #x85.

The characters #x85 and #x2028 cannot be reliably recognized and translated until an entity's encoding declaration (if present) has been read. Therefore, it is a fatal error to use them within the XML declaration or text declaration.

[Insider2004]

Den Standard habe ich jetzt nicht gelesen, ich habe aber mehrere XML-Parser entscheidend mit entwickelt und wusste diesen Fakt.