Trennung von GUI und Logik, wie geht ihr vor?

[Stevie]

Zitat von haentschman:

Moin...

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.

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

Zitat:

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

...nicht ganz.
ZITAT:

Zitat:

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

[freimatz]

ok, ok
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 von Chemiker:

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 von Chemiker:

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 von Chemiker:

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 von Chemiker:

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 von Chemiker:

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 von Chemiker:

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 von Chemiker:

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.