|
AW: MVVM in der Realität
Zitat:
Für die Austauschbarkeit der Views hatte ich von Anfang an immer eine Zwischenschicht drin, so dass der Presenter eben nicht direkt das Formular kennt, sondern eben nur das was der View ihm abstrahiert. Praktisch hat mir das aber eigentlich keinen Nutzen gebracht - und wenn ich nochmal von Null anfangen würde, würde ich darauf komplett verzichten. Verschiedene Views brauchen (spätestens nach 5 Minuten im praktischen Einsatz) immer andere Models. Bei einem anderen View ist eben der Anwendungsfall immer leicht anders - dann braucht der Views vom Model bald auch leicht andere Daten, ... das driftet dann sehr schell auseinander. Bleibt noch der Fall wo der View wirklich identisch ist (Plattformwechsel, Komponentensetwechsel). - zur Plattformunabhängigkeit würde ich dann lieber gleich ein plattformübergreifendes Komponentenset nehmen (LCL). - Wenn ich wirklich mal komplexe Komponenten gewechselt habe (verschiedene TreeView und Grids), habe ich mir "Interaktoren" als Abstraktionsschicht zwischen Presenter und Komponente geschrieben. Für den Presenter sehen dann z.B. in VirtualTreeView-Interactor und irgendein DevExpressTreeView-Interactor gleich aus (selbe Basisklasse). |
AW: MVVM in der Realität
Ich will das Thema nochmal hervorholen...
Bei Video2Brain ist ein Tutorial zu MVVM mit Prism unter WPF erschienen.  https://www.video2brain.com/de/video...mvvm-und-prismWPF kann man ja sicher als das Paradebeispiel für MVVM ansehen, schließlich unterstützt es MVVM "nativ". Wenn man dann noch ein Framework her nimmt, das nochmal alles vereinfachen soll (in dem Fall Prism), dann sollte alles easy und selbsterklärend funktionieren. Das sehe ich aber überhaupt nicht. Ich bin regelrecht erschrocken, was man dort alles regeln und beachten muss, damit man die eigene Anwendung in´s Laufen kriegt. Sicher, machbar ist das, aber als Wunschlösung würde ich das nicht mal annähernd ansehen... Wie seht Ihr das? (Wer das Video nicht sehen kann oder will und Prim nicht selbst nutzt ist hier natürlich schon mal durch´s Raster gerutscht. ;-) ) |
AW: MVVM in der Realität
MVVM hat Vorteile aber auch Nachteile. Damit muss man leben, wenn man damit hantieren will.
Warum nimmt man MVVM?
Und damit das auch alles geteilt werden kann, hat man sich eben dieses MVVM ausgedacht. Niemand hat gesagt, das MVVM Plug'n'Play ist, denn das ist es definitiv nicht. Es ist auch aufwändiger in der Implementierung. Dafür kann ich das Projekt aber aufteilen, die einzelnen Teile in sich testen und am Ende - wenn alle die Verträge eingehalten haben - alles zusammenführen und habe eine lauffähige Anwendung. Spätere Änderungen können dann relativ einfach eingeführt werden, denn durch die strenge Entkoppelung wirken sich Änderungen in einer Schicht nicht unmittelbar auf eine andere Schicht aus. Jede Schicht kann ganz gemütlich für sich entwickelt und getestet werden. WPF greift dem GUI-Team sehr stark unter die Arme, weil das Binding fast von selbst läuft, die anderen Teams haben davon gar nichts. Insgesamt besteht eine Anwendung nachher nicht nur aus View-Model-ViewModel, sondern auch noch aus DTO (DataTransferObject), Services, ... (um nur ein paar Schlagworte zu verwenden. |
AW: MVVM in der Realität
Ok, das ist eine schöne und plausible Erklärung.
Für verschiedene Teams, die jeweils einzelne Projektteile bearbeiten, macht das Sinn. Das kann ich nachvollziehen. Den Aufwand kann man dann auch verkraften und zieht insgesamt durchaus Vorteile. Für Einzelentwickler ist das dann wahrscheinlich nicht unbedingt der sinnvollste Weg. Ich hatte das als "schöne neue Welt" angesehen (Plug&Play ist auch gut als Bezeichnung), die einfacher und bunter ist - aber das ist es dann halt doch nicht. |
AW: MVVM in der Realität
Zitat:
Man(n) steht ja nicht morgens auf und überlegt sich - heute ist ein schöner Tag um mit MVVM zu beginnen... Spätestens jedoch wenn man ein bisschen mehr Unit-Tests machen möchte, stellt man plötzlich fest - ohh doof ist ja im Formular... Wenn man dann so vor sich hin programmiert, stellt man fest, dass die zeit bis zu einem Erflogreichen <F9> und man sieht etwas auf dem Bildschirm - deutlich länger ist... Als Clicky-Rad-Button-Coderein... Aber die Möglichkeiten werden immer weitgehender... Und das macht einfach Spass... Mavarik |
AW: MVVM in der Realität
Zitat:
Wir setzen MVVM mit Delphi seit einien jahren ein. Das Framework ist selbst gemacht. Sehr aufwendig. RTTI mit Delphi ist ein Qual. Anderen Nachteile wurden ja schon geannt, Vorteile auch. Unschön finde ich auch, dass man die Logik im VM suchen muss, der Anteil leigt bei uns bei gefühlt 5% |
AW: MVVM in der Realität
Ich würde jetzt nicht sagen, das VCL und MVVM zusammenpassen. Für Delphi würde ich das auch nicht einsetzen. Im Web-Bereich und bei WPF sieht das schon ganz anders aus.
Die Trennung von UI und BL kann man auch anders hinbekommen, da braucht's kein MVVM. |
AW: MVVM in der Realität
Zitat:
Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist. Ich seh nämlich zum Beispiel gerade nicht, wo man bei MVVM großartig mit RTTI Probleme bekommt. Bissle Werte von a nach b schuffeln durch irgendwelche Databindings und das wars doch. Zitat:
Aber wenn man sich Angular, Knockout oder andere Vertreter anschaut, dann schaut das schon enorm schön aus, wie man seine Daten so in die entsprechenden Stellen bringen kann. |
AW: MVVM in der Realität
Zitat:
|
AW: MVVM in der Realität
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 12:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz