MVVM Framework für Delphi
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 ;) |
MVVM Framework für Delphi VCL/FMX
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? |
AW: MVVM Framework für Delphi
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 |
AW: MVVM Framework für Delphi
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. ;-) |
AW: MVVM Framework für Delphi
@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. |
AW: MVVM Framework für Delphi
DSharp hast Du Dir bereits angeschaut?
|
AW: MVVM Framework für Delphi
Zitat:
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) |
AW: MVVM Framework für Delphi
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. |
AW: MVVM Framework für Delphi
Zitat:
|
AW: MVVM Framework für Delphi
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 ;) |
AW: MVVM Framework für Delphi
Zitat:
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: |
AW: MVVM Framework für Delphi
Zitat:
|
AW: MVVM Framework für Delphi
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. |
AW: MVVM Framework für Delphi
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: |
AW: MVVM Framework für Delphi
@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(!). |
AW: MVVM Framework für Delphi
Zitat:
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". |
AW: MVVM Framework für Delphi
Zitat:
Zitat:
Danke für eure Posts! |
AW: MVVM Framework für Delphi
Zitat:
Delphi-Quellcode:
mit den Minimal-Eigenschaften
CommandViewModel
Delphi-Quellcode:
. Den Button (besser eine Action nehmen und die an den Button) verknüpft man nun einfach mit diesem
Execute
Delphi-Quellcode:
und schon ist alles gesagt, was gesagt werden muss.
CommandViewModel
Weiterhin habe ich im ViewModel nicht nur die Möglichkeit der Daten-Transformation, sondern auch das Bereitstellen von Lookup-Listen.
Delphi-Quellcode:
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.
TPersonViewModel = class( ... )
public // Benachrichtigung property PropertyChanged; // Multicast-Event // Lookup propery GenderList; // Daten-Felder property Gender : Integer; property FirstName : string; property LastName : string; end; 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 :) |
AW: MVVM Framework für Delphi
Zitat:
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 |
AW: MVVM Framework für Delphi
@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. |
AW: MVVM Framework für Delphi
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.
|
AW: MVVM Framework für Delphi
@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:
Das ViewModel bekommt bei der Erzeugung eine Instanz von
TDataPerson class
+ Firstname + Lastname + Sex TPersonViewModel class - DataPerson - DataPersonDTO + Firstname + Lastname + Sex
Delphi-Quellcode:
mit auf den Weg.
TDataPerson
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:
ist in
Sex
Delphi-Quellcode:
und im DTO sagen wir mal vom Typ
TDataPerson
Delphi-Quellcode:
.
Integer
Das ViewModel gibt aber diese Eigenschaft als Typ
Delphi-Quellcode:
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.
TSexViewModel
Erst dann macht das mit dem MVVM Sinn und Spass. |
AW: MVVM Framework für Delphi
@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). |
AW: MVVM Framework für Delphi
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. |
AW: MVVM Framework für Delphi
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. |
AW: MVVM Framework für Delphi
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.
|
AW: MVVM Framework für Delphi
: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. |
AW: MVVM Framework für Delphi
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? |
AW: MVVM Framework für Delphi
Zitat:
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 |
AW: MVVM Framework für Delphi
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:
Es wird im TRttiInterfaceType versucht auf IsGenericTypeDefinition zuzugreifen, was aber nicht existiert, ebenso gibt es keine TryConvert Methode in TValue.
[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 Weis jemand mit welchen Stand bzw. Version von Delphi, Spring4D, DSharp, VirtualTreeView, ... es funktionieren könnte? |
AW: MVVM Framework für Delphi
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: |
AW: MVVM Framework für Delphi
Zitat:
|
AW: MVVM Framework für Delphi
Zitat:
Zitat:
|
AW: MVVM Framework für Delphi
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:
Gerade bei Spring4D haben wir extra einen Entwickler, der alle Features auf Mobile testet und auch einsetzt. |
AW: MVVM Framework für Delphi
@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? |
AW: MVVM Framework für Delphi
Zitat:
|
AW: MVVM Framework für Delphi
Zitat:
|
AW: MVVM Framework für Delphi
Hast Du dafür eine Quelle?
|
AW: MVVM Framework für Delphi
Stevie hat schon den Grund genannt. Aber der Insider hat da natürlich mehr Einblick.
Sogar mehr als die Autoren von XML! Zitat:
|
AW: MVVM Framework für Delphi
Den Standard habe ich jetzt nicht gelesen, ich habe aber mehrere XML-Parser entscheidend mit entwickelt und wusste diesen Fakt.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:54 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz