Trennung von GUI und Logik, wie geht ihr vor?

[Stevie]

Zitat von Mavarik:

Zitat von Stevie:

Eigentlich ist es recht unmissverständlich definiert - siehe https://msdn.microsoft.com/en-us/lib...8246.aspx#sec7

Die Frage ist eher, wie sehr man die Daten kapselt.

Ja "unmissverständlich" wird gesagt, dass das VM die Daten aus dem Model auch ggf. Interpretiert und ggf. anders an die View weiter gibt.

Also hat das VM ggf. auch intern eine eigenen Datenbestand für die View...

Der Kernpunkt ist, dass das VM die Kontrolle darüber hat, was in beide Richtungen fließt.

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 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). Wenn es nun so sein soll, dass ich die 3. Eigenschaft nur befüllen kann, wenn die 2 anderen Eigenschaften bestimmte Werte haben, dann gibt es eine "Eigenschaft3Enabled" Eigenschaft im ViewModel, welche an das entsprechende UI Control für diese Eigenschaft gebunden wird und durch Änderungen der anderen beiden Eigenschaften im ViewModel beeinflusst wird. Hierbei sorgen die Bindings und ein entsprechende Benachrichtigungssystem für das Updaten in beide Richtungen:

In der UI in den Controls für Eigenschaft 1 oder 2 was geändert -> binding aktualisiert das VM -> "Eigenschaft3Enabled" wird ggf verändert -> "Eigenschaft3Enabled hat sich geändert" Notification triggert -> binding bekommt das mit -> UI Control für Eigenschaft 3 wird entsprechend an oder ausgeschaltet

D.h. irgendwelche Businesslogik wird in den meisten Fällen nichtmal im ViewModel gehandhabt sondern im Model. Das ViewModel ist quasi nur die Abstraktion der UI. Dort steht drin, dass bei der Konstellation XY die CheckBox Z angezeigt wird oder nicht.

Und genau jetzt ergibt sich oft die Tücke, dass gewisse Dinge dann doch irgendwie Businesslogik sind und Teil des Models sind (komplexe Regel validierung, etc), aber doch bitte in der UI reflektiert werden soll. Das muss dann immer komplett durch das ViewModel hin und zurück fließen - guckstu https://stackoverflow.com/questions/...or-a-viewmodel

Das heißt also, dass hier das VM schon mehr Teil der UI als der Businesslogik ist - schaust du hier: https://stackoverflow.com/questions/...ttern-and-mvvm
Wenn du dir den 2. Grund anschaust, warum MVVM so toll ist/sein soll, dann wird klar, warum das in Delphi in dieser Form so schnell zusammen fällt, da gibs kein Blend. Rapid Prototyping funktioniert bei uns ein bisschen anders (TPrototypeBindSource, TClientDataSet etc).

[Mavarik]

Zitat von Stevie:

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

Zitat von Stevie:

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

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

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

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.

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