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