Trennung von GUI und Logik, wie geht ihr vor?

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1387642)

Lass uns nochmal kurz definieren, was bei MVVM Model und ViewModel sind.

Bei dem Model kann es sich um eine simple TCustomer Klasse mit 5 string Eigenschaften und sonst nix handeln oder um eine TSpeicherDruckUndSchickEmailsKlump Klasse mit siebenundöffzig Methoden.

Das mag ja alles richtig sein und in einem Umfeld mit 150 anderen Programmierern sollte man sich sicherlich streng an ein Pattern halten...

Aber für mich oder meine App, von der niemand jemals den Sourcecode sehen wird, spielt es nicht so einen große Rolle...

Daher schreibe ich immer MVVM (oder was ich dafür halte)... Ob ich nun etwas von Pattern abweiche und mein VM etwas mehr macht als es sollte oder was auch immer... Mein Source, meine Regeln...

Hauptsache die Trennung von UI und Code ist solide, keine fest verlinkten Beziehungen und die Testbarkeit ist gegeben... Das reicht mir...

Abgesehen davon Druck und schick Emails würde bei mir NIE in einem Model landen, sondern eine Drückroutinen würde wenn überhaupt das Model als Interface bekommen und ggf. so einen Controller als Zwischenschicht.

Für mich ist es wichtiger pflegbaren Sourcecode zu haben, den ich auch mit Delphi-Techniken vernünftig erzeugen kann.
Also ein bisschen RAD, so wenig wie möglich klicken und am besten den OI nur fürs Form... So finde ich auch alle Änderungen im Repro...
Daher auch keine visual-live-Bindings...

Mavarik

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1387656)

Zitat:

Zitat von Stevie (Beitrag 1387642)

Das ViewModel abstrahiert die Funktionialität des Models, die in der View benutzt wird und bereitet sie entsprechend auf. Wenn ich von den 5 Eigenschaften nur 3 Anzeige, dann gibt es möglicherweise nur genau diese 3 Eigenschaften im ViewModel (caching, edit, save, cancel etc mal außen vor gelassen).

Eben diese Doppelung will ich mir ersparen und binde einfach nur drei Controls an 3 von 5 Eigenschaften.

Das kannst du gerne machen, aber das ist dann kein MVVM, weil die View direkt mit dem Model kommuniziert und möglicherweise Dinge im Model erfordert, die nicht Teil seiner Aufgabe sind (hallo SRP) wie z.B. Benachrichtigung beim Ändern von Eigenschaften.

Zitat:

Zitat von Mavarik (Beitrag 1387731)

Daher schreibe ich immer MVVM (oder was ich dafür halte)... Ob ich nun etwas von Pattern abweiche und mein VM etwas mehr macht als es sollte oder was auch immer... Mein Source, meine Regeln...

Ich persönlich finde ja, wenn man sowas öffentlich irgendwo anderen Entwicklern vorträgt, sollte man auch korrekte Begrifflichkeiten benutzen.
Ja, MVVM auch in anderen Sprachen hat viele Ausprägungen, aber es finden sich immer wieder bestimmte Kernanforderungen wieder - und wenn man die nunmal nicht hat, kann man auch nicht von MVVM sprechen, so seh ich das.

[Ghostwalker]

Moinsen,

hab mir nun den Thread durchgelesen, da mich das Thema auch immer wieder beschäftigt. Persönlich ziehe ich aus dieser Diskussion den Schluss, das es keinen goldenen Weg gibt.

Wichtig sind meiner Meinung nach folgende Punkte:


a) Im Team sollte man sich in einer Diskussion auf einen Weg einigen und diesen auch konsequent verfolgen.

b) Man sollte prüfen ob der zu erwartende Projektumfang es überhaupt notwendig macht, ein entsprechendes Pattern um zu setzen. Es ist imho ineffizient, wenn ich auf ein Pattern poche und ggf. den Code verdreifache, nur damit es dem Pattern genügt.

c) Hat man schließlich ein Projekt entsprechenden Umfangs, würde ich mir überlegen, wo der Schwerpunkt der Anwendung liegt. Hab ich ein relativ einfaches Datenmodel und dafür eine komplexe UI um den Anwender die Daten entsprechende zu präsentieren bzw. entsprechende Eingaben zu erlauben, so macht das MVVM-Pattern sicher Sinn. Liegt der Schwerpunkt da gegen mehr auf dem zu grunde liegenden Datenmodel, so wär sicher zu überlegen, ob hier nicht das MVC/MVP Pattern sinniger wär.

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1387755)

Das kannst du gerne machen, aber das ist dann kein MVVM, weil die View direkt mit dem Model kommuniziert und möglicherweise Dinge im Model erfordert, die nicht Teil seiner Aufgabe sind (hallo SRP) wie z.B. Benachrichtigung beim Ändern von Eigenschaften.

Ich habe meinen Ansatz nicht als MVVM bezeichnet sondern sehe ihn als bessere Alternative.
Die Benachrichtigungen in beide Richtungen übernimmt das Framework automatisch. In einzelnen Klassen und Properties muss dazu nichts geschrieben werden.

Ggf. kann man eine Eigenschaft einführen, die nur von der GUI benötigt wird (z.B. Fullname, der Firstname und Lastname kombiniert).
In der Buinesslogik kann man ja diese Eigenschaft einfach nicht verwenden.
Denkbar wäre auch, solche Properties in einer Sektion "gui" statt "public" aufzunehmen, so dass sie nur von der GUI aus erreichbar sind. Das könnte dann die Member noch etwas übersichtlicher strukturieren.

[haentschman]

Moin...:P

Zitat:

Wie könnte man dieses Beispiel als MVC ohne zusätzliche Bibliothek umgestaltet werden?

Dei 4 Seiten diskutiert ihr über MVVM als Definition. Eine konkrete Umsetzung sehe ich nicht. Macht doch mal dieses Beispiel mit der Addition nach MVVM ausschließlich mit Bordmitteln. Das ist das was der TE möchte. Dann kann der TE doch entscheiden welche Variante er bevorzugt. :zwinker:

[Stevie]

Zitat:

Zitat von haentschman (Beitrag 1387799)

Moin...:P

Zitat:

Wie könnte man dieses Beispiel als MVC ohne zusätzliche Bibliothek umgestaltet werden?

Dei 4 Seiten diskutiert ihr über MVVM als Definition. Eine konkrete Umsetzung sehe ich nicht. Macht doch mal dieses Beispiel mit der Addition nach MVVM ausschließlich mit Bordmitteln. Das ist das was der TE möchte. Dann kann der TE doch entscheiden welche Variante er bevorzugt. :zwinker:

Das hab ich schon im 2. Post und wie ich vor einigen Seiten schon erwähnte geht MVVM nicht einfach nur mit Bordmitteln, da es z.B. nicht möglich ist, Methoden per LB zu binden.

[freimatz]

Der TE möchte nicht MVVM sondern "Trennung von GUI und Logik", das Thema MVVM kam erst später.
Für den TE empfehle ich als erstes MVVM auch gar nicht.

[Wosi]

OK, zurück zum Thema!

Ob du nun MVC, MVP, MVVM oder sonst irgendein Pattern für die Trennung zwischen UI und der Business-Logik anwendest, ist erst mal völlig egal.
Es ist auch egal, ob du irgendein Framework einsetzt oder alles zu Fuß machst. Frameworks helfen dir dabei wiederkehrende Arbeiten zu erleichtern. Man lernt sie meiner Meinung nach erst richtig schätzen, wenn man die Dinge eine Zeit lang manuell gemacht hat.

Ich habe ein kleines MasterMind-Spiel geschrieben, bei dem der Spiel-Ablauf und dessen Logik vollständig von der Oberfläche getrennt sind:

https://github.com/Wosi/MasterMind

Die Architektur entspricht am ehesten den Model-View-Presenter (MVP) Pattern.
Der Presenter steuert den Spiel-Ablauf und weist das View-Objekt an das Spielfeld neu zu zeichnen und auf den nächsten Versuch des Spielers zu warten etc. Das View-Objekt wird hinter einem Interface versteckt, sodass es egal ist ob es sich dabei um eine Form oder irgendetwas anderes handelt.

In dem Projekt gibt es drei unterschiedliche View-Implementierungen:
- Eine Form
- Eine Klasse für das Spiel auf der Konsole
- Ein Mock, mit dessen Hilfe ich den Presenter testen kann

Vielleicht hilft das dem einen oder anderen weiter.

P.S: Das sind jetzt alles Lazarus- bzw. FreePascal-Projekte aber für das Konzept ist das erstmal irrelevant.

[haentschman]

Moin...:P

Zitat:

Der TE möchte nicht MVVM sondern "Trennung von GUI und Logik", das Thema MVVM kam erst später.

...nicht ganz. :zwinker:
ZITAT:

Zitat:

anders gefragt, gibt es empfehlenswerte Seiten, wo wann MVC oder MVVM für Pascal nachlesen kann?

[freimatz]

ok, ok :pale:
Auf diese Frage meine Antwort: Nein gibt es nicht. :(

[Chemiker]

Hallo zusammen,

ich frage mal ganz ketzerisch, welche Vorteile bring es das GUI von der Geschäftslogik zu trennen?

Die Programmgeschwindigkeit ist es wahrscheinlich nicht, durch die Übergaben der Daten werden zusätzliche Befehle notwendig die die Geschwindigkeit des Programms verringert.

Besser Wartbarkeit? Ich weis nicht, wenn eine Datenbank-Anwendung um ein neues Datenbankfeld erweitern werden muss, so muss diese Änderung in allen Modulen berücksichtig werden.

Besser Testen? Man muss die Übergaben der Module zusätzlich testen, dass bedeutet erstmal Mehraufwand.

Man kann die GUI austauschen, wirklich? Entwickelt wurde für einen Destop-PC, jetzt soll das Programm auch auf Mobilgeräte laufen, auch hier kommt man nicht herum in den meisten Modulen eine Anpassung durchzuführen. Man braucht sich ja nur mal Windows 10 ansehen, wie es aussieht, wenn man versucht ein Destop-Programm auch für Mobilgeräte fit zu machen.

Ich finde das diese Entwurfsmuster auch dazu führen, dass man einfach drauflosentwickelt, man nennt das dann einfach „agil“ und schon ist alles OK.

Außerdem, für viele Probleme gibt es kein Muster, oder jedenfalls kein bekanntes Muster, entweder weil das Problem zu selten auftritt oder weil es jeweils ganz spezifisch im jeweiligen Kontext neu gelöst werden muss.

Dieser Beitrag soll nur zum Nachdenken anregen, weil man sich vor Extreme hüten sollte.

Bis bald Chemiker

[Stevie]

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Die Programmgeschwindigkeit ist es wahrscheinlich nicht, durch die Übergaben der Daten werden zusätzliche Befehle notwendig die die Geschwindigkeit des Programms verringert.

In gewissem Maße zu vernachlässigen - UI Code muss kein Highperformance Code wie auf nem 24/7 Server sein - natürlich sollte man hier keine Verzögerungen haben, dass die UI zäh wird.

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Besser Wartbarkeit? Ich weis nicht, wenn eine Datenbank-Anwendung um ein neues Datenbankfeld erweitern werden muss, so muss diese Änderung in allen Modulen berücksichtig werden.

Auf jeden Fall, es geht darum, Zuständigkeiten zu trennen. Natürlich muss ich auch dann noch im Datenmodell, im Presenter/Controller/whatever und in der UI dafür sorgen, dass das neue Feld auch richtig funktioniert. Aber es ist klarer, wo und was ich ändern muss, als wenn alles ein großer Klump ist - und wir reden hier nicht von einfach nen Dataset, DataSource, Grid, fertig Anwendung - da würd ich auch kein MVC/MVP/MVVM praktizieren.

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Besser Testen? Man muss die Übergaben der Module zusätzlich testen, dass bedeutet erstmal Mehraufwand.

Hier kommt ein Vorteil beim Einsatz eines Frameworks/Bibliothek zum tragen, das teste ich einmal und weiß, dass es funktioniert. Viele dieser Bibliotheken verfügen auch über Mechanismen zum Protokollieren, so dass man sehen kann, wenn irgendwo eine Verbindung fehlt oder nicht passt. Zudem gibt es noch einen Vorteil wenn man das sogenannte Convention over Configuration einsetzt (zugegeben, das kann zu Beginn schon arg "magic" sein) - aber es befreit von manuellem Anstöpseln der verschiedenen Teile.

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Man kann die GUI austauschen, wirklich? Entwickelt wurde für einen Destop-PC, jetzt soll das Programm auch auf Mobilgeräte laufen, auch hier kommt man nicht herum in den meisten Modulen eine Anpassung durchzuführen. Man braucht sich ja nur mal Windows 10 ansehen, wie es aussieht, wenn man versucht ein Destop-Programm auch für Mobilgeräte fit zu machen.

Dein Vergleich hinkt. Bei der Entkopplung der Businesslogik von der UI kann ich mir für jede Plattform die UI so basteln, wie ich mag, aber wenn die Geschäftslogik (Validierung, triggern von anderen Komponenten, verbindung zur Datenbank, whatever) nicht direkt an die UI, ihre Events (kurz code behind, aka "onclick programmming") geklöppelt sind, dann kann man die so 1 zu 1 wiederverwenden.

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Ich finde das diese Entwurfsmuster auch dazu führen, dass man einfach drauflosentwickelt, man nennt das dann einfach „agil“ und schon ist alles OK.

"Agil" heißt keineswegs einfach drauf los - aber das zu diskutieren, wäre besser in einem eigenen Thread aufgehoben.

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Außerdem, für viele Probleme gibt es kein Muster, oder jedenfalls kein bekanntes Muster, entweder weil das Problem zu selten auftritt oder weil es jeweils ganz spezifisch im jeweiligen Kontext neu gelöst werden muss.

Bedingt. Wenn man sich mal näher mit Entwurfsmustern beschäftigt, wird man erstaunt sein, wo man sie überall wiederfindet oder auch "aus Versehen"/ohne es zu wissen selbst eingesetzt hat.
Aber dazu gehört auch zu wissen, wann man etwas anders machen muss, weil...

Zitat:

Zitat von Chemiker (Beitrag 1388177)

Dieser Beitrag soll nur zum Nachdenken anregen, weil man sich vor Extreme hüten sollte.

Da stimme ich dir uneingeschränkt zu - aber je mehr Möglichkeiten man kennt, desto besser kann man entscheiden, wie man etwas löst und wo man vom "Standard" abweichen muss.

[stahli]

Die Trennung der Zuständigkeiten und die damit verbundene bessere Übersichtlichkeit des Codes finde ist das wesentliche Kriterium.

Wenn man das Alter einer Person anzeigen will, sollte man dieses nicht im Formular berechnen.

Besser ist es, dies in der Personenklasse zu tun und ein Label dann an dieses Property zu binden.
So muss man später nicht verschiede Stellen suchen, wo man eine entsprechende Berechnung durchgeführt hat.
In der Klasse kann man diese Berechnung jederzeit ändern, ohne dass das die GUI interessieren muss.

Soweit sollte das jedem einleuchten, der schon länger objektorientiert programmiert.

Selbst, wenn man die GUI nicht irgendwann mal austauschen oder Tests für die BL einrichten will, profitiert man von einer solchen Trennung.

Im Grunde ist diese Trennung schon vorhanden, wenn die BL komplett in einfachen Klassen läuft und die Formulare lediglich auf die Objekte zugreifen.

Wenn man sich den Klebecode sparen kann und ein Framework benutzt, wird das Ganze natürlich noch effektiver.

Die Bindung kann man dann direkt zwischen GUI und BL organisieren oder nochmal Controller dazwischen setzen, die die Daten nochmal überprüfen und aufbereiten.


Also es gibt viele mögliche Ausprägungen, aber wichtig und sinnvoll ist, dass die GUI niemals irgend etwas selbst tut, das strukturell eigentlich zur Geschäftslogik gehört. Dann ist das Projekt längerfristig sehr viel wartbarer.

[freimatz]

Zitat:

Zitat von stahli (Beitrag 1388190)

Soweit sollte das jedem einleuchten, der schon länger objektorientiert programmiert.

Sollte. Leider ist dem nicht so. :roll:

Man muss ja nicht ins andere Extrem fallen wie an dem Code wo ich grad dran bin bei dem zwischen Anwender und DB ca. sieben Schichten liegen. :-D (Wohlgemerkt bei einer Desktop-Anwendung)

[mschaefer]

Moin, die normale VCL Anwendung fördert die Trennung nicht wirklich. Denke das dies bei Windows Applikationen auch bis zu einem gewissen Grad vertretbar ist die Logik mit dem Formular zu verknüpfen, für Webanwendungen mit Webformular und serverside Execution geht es schlicht nicht.

Solange mit Delphi nicht ernsthaft Weboberflaechen entwickelt werden können, wird es wohl keine saubere Trennung geben.

Grüße in die Runde :-)

[p80286]

Zitat:

Zitat von mschaefer (Beitrag 1388260)

Moin, die normale VCL Anwendung fördert die Trennung nicht wirklich.

Das kann ich unterschreiben. Und wenn man dann ein zweites Programm mit der gleichen und dann noch zusätzlicher Funktionalität schreibt, fängt man an das erste Programm zu filetieren und nimmt sich vor es beim nächsten Mal gleich zu trennen, egal ob es zunächst einfacher erscheint oder nicht.

Gruß
K-H

[Ghostwalker]

Zitat:

Zitat von mschaefer (Beitrag 1388260)

Moin, die normale VCL Anwendung fördert die Trennung nicht wirklich. Denke das dies bei Windows Applikationen auch bis zu einem gewissen Grad vertretbar ist die Logik mit dem Formular zu verknüpfen, für Webanwendungen mit Webformular und serverside Execution geht es schlicht nicht.

Solange mit Delphi nicht ernsthaft Weboberflaechen entwickelt werden können, wird es wohl keine saubere Trennung geben.

Grüße in die Runde :-)

Das kann ich so nicht ganz unterschreiben. Auch in Webanwendungen kann man einen Teil der Logik an die Oberfläche binden. Mit Javascript nicht wirklich ein Problem. Andererseits hast du schon recht, das bei Webanwendungen eine stärkere Trennung vorhanden ist. Das liegt aber daran, das ich i.d.R. auch eine "physikalische Trennung" habe (eben Browser/Client und Server). Das erleichtert dann natürlich auch die Trennung von Gui und Logik.

Eine solche Trennung kann man aber genauso mit VCL oder mit jedem anderen Oberflächenframework bewerkstelligen.

[Mavarik]

Egal wie man etwas trennt... Eine Schichttrennung hat immer Vorteile.

Wer hat sich nicht schon mal geärgert das man die Datenbank X gegen eine andere Datenbank tauschen möchte oder auch nur andere Zugriffskomponenten (BDE zu FireDac z.B.)

Hat man je Formular zig Komponenten drauf geklickt ist das der Horror... Dann noch alle Verbindungen im Objectinspector zusammen geklöppelt und wahrscheinlich alle Felder oder Grids mit Datasets verknüpft... Oder noch schlimmer per LiveBindings...

Für ein Prototype mag das noch gehen, aber für eine Anwendung die ggf. sogar mehrere Programmierer pflegen sollen? Naja...

Alles in ein Form zu packen rächt sich sehr schnell...

Wer es so gemacht hat, soll doch mal eben von FireDac & lokaler Interbase Datenbank auf einen REST-Server / SOAP umstellen...

Ich tausche nur ein Interface im Model...

Mavarik

[Frickler]

Zitat:

Zitat von Mavarik (Beitrag 1388306)

Hat man je Formular zig Komponenten drauf geklickt ist das der Horror... Dann noch alle Verbindungen im Objectinspector zusammen geklöppelt und wahrscheinlich alle Felder oder Grids mit Datasets verknüpft... Oder noch schlimmer per LiveBindings...

Um das Verdrahten der Komponenten auf den Forms (selbst wenn mans mit der Controllerklasse verdrahtet in der PAS Datei) kommt man eigentlich nur drumrum, wenn man die Forms automatisch generiert, entweder zur Entwicklungszeit aus dem Datenmodell oder gar zur Laufzeit aus den aktuellen Daten.

[Mavarik]

Zitat:

Zitat von Frickler (Beitrag 1388308)

Um das Verdrahten der Komponenten auf den Forms (selbst wenn mans mit der Controllerklasse verdrahtet in der PAS Datei) kommt man eigentlich nur drumrum, wenn man die Forms automatisch generiert, entweder zur Entwicklungszeit aus dem Datenmodell oder gar zur Laufzeit aus den aktuellen Daten.

Oder man bindet die Komponenten nur an propertys des ViewModels und brauch "nie" wieder etwas am Form ändern.

[mkinzler]

https://blog.grijjy.com/2018/01/22/m...t-part-1-of-3/

[freimatz]

Daaaaaanke!
Unser Framework ist ähnlich aufgebaut.

[mkinzler]

2. Teil jetzt online

https://blog.grijjy.com/2018/01/24/m...t-part-2-of-3/

[hzzm]

Mal 'ne Frage:

Basierend auf den Diagrammen von
Model-View-Controller, Model-View-Presenter, Model-View-ViewModel,
speziell Figure 5:

Ist es MVP-gerecht, die "Observer<->Data Access"-Beziehung nicht zwischen Model<->View, sondern ueber den Mediator Presenter laufen zu lassen?
Der Presenter wuerde also das Model observen und bei notify in seiner View reagierend schalten, waehrend er von der View nach Strategy-Pattern Aenderungen direkt an das ihm gehoerende Model geben wuerde.

Waere das Passive vs. Supervising Presenter?
Oder gar kein MVP mehr?

Wenn das legitim ist, haette man ja wirklich null interaktion zwischen Model und View, sprich nur der Presenter waere noch Model-spezifisch.

Edit: Hat sich erledigt. Mit Mediator heisst es Model-View-Adapter

[QuickAndDirty]

@hzzm
Ich habe MVP immer so umgesetzt.
In der "program" Datei (*.dpr)
Werden die Presenter erzeugt.
Im Konstrukor der Presenter werden View und Model als Interface Parameter übergeben.
Im Konstruktor des Presenters werden View und Model dann mit eineander verdrahtet (Observer werden Registriert usw.)

Delphi-Quellcode:

KannWasPresenter := TKannWasPresenter.create((TKannWasView.create)as IKannWasView, (TKannWasModel.create) as IKannWasModel) as IKannWasPresenter;

Mein Presenter war immer ein reiner Gluecode-Container! Ich weiß nichtmal ob das so noch MVP heißt,
aber es hat echt gut funktioniert und es mir ermöglicht TModel in verschiedenen Projekten wieder zuverwenden.

Leider habe ich danach einen Ausflug in die Welt von MVVM und Livebindings gemacht :(
Und das war ein Fehler.
Meine Version von MVP hat mir echt mehr gebracht.

Jetzt habe ich mein MVVM projekt komplett von Livebindings befreit, weil ich zu dumm dafür bin....
Dadurch letzten Endes Viel Code in TForm Klassen und eine aufgeblähte VM Klasse dazwischen,
von der ich eigentlich nur die Navigations funktionalität bräuchte...

[hzzm]

Zitat:

Zitat von QuickAndDirty (Beitrag 1392364)

Leider habe ich danach einen Ausflug in die Welt von MVVM und Livebindings gemacht :(
Und das war ein Fehler.
Meine Version von MVP hat mir echt mehr gebracht.

Jetzt habe ich mein MVVM projekt komplett von Livebindings befreit, weil ich zu dumm dafür bin....
Dadurch letzten Endes Viel Code in TForm Klassen und eine aufgeblähte VM Klasse dazwischen,
von der ich eigentlich nur die Navigations funktionalität bräuchte...

Das haelt mich auch von MVVM ab. Wenn ich gaengige MVVM Implementationen lese, draengt sich mir immer ein Gedanke auf:

Over-engineered.

Suess in der Theorie, in der Praxis aber viel zu viel gefummele. Entkopplung muss auch einfacher gehen.