AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

MVVM Framework für Delphi

Ein Thema von mquadrat · begonnen am 1. Nov 2010 · letzter Beitrag vom 19. Jan 2015
Antwort Antwort
Seite 2 von 6     12 34     Letzte » 
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.123 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: MVVM Framework für Delphi

  Alt 15. Jan 2015, 18:56
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
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.364 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: MVVM Framework für Delphi

  Alt 15. Jan 2015, 20:53
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
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#13

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 01:16
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#14

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 02:30
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#15

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 08:08
@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(!).
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#16

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 08:12
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".

Geändert von Dejan Vu (16. Jan 2015 um 08:15 Uhr)
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.364 Beiträge
 
Delphi 10.3 Rio
 
#17

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 09:25
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

@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!
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#18

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 10:42
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 CommandViewModel mit den Minimal-Eigenschaften
  • DisplayName
  • Enabled
sowie einer Methode Execute . Den Button (besser eine Action nehmen und die an den Button) verknüpft man nun einfach mit diesem 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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.123 Beiträge
 
Delphi 10.3 Rio
 
#19

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 11:57
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
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#20

AW: MVVM Framework für Delphi

  Alt 16. Jan 2015, 13:33
@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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (16. Jan 2015 um 13:40 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:07 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