MVVM Framework für Delphi

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