Monday, May 23, 2016

MVVM - Oder was ich dafür halte...

Mit diesem Satz beginne ich eigentlich immer, wenn ich über MVVM spreche...

Angefangen hat es hiermit und nun? Natürlich bin ich ein gutes Stück weiter, aber gerade habe ich ein Video von 2014 (Visual Studio Tollbox / channel8.msdn.com / MVVM Best Practices ) gefunden... Die beste Aussage aus dem Video ist zwischen 02:45 - 03:45.

"Egal" wie man es nennt... Es geht um ein Pattern - wie auch immer man es implementiert.

Trotzdem habe ich mich jetzt daran gewöhnt die drei Jungs beim "richtigen" Namen zu nennen.

View -> ViewModel -> Model.

Natürlich habe ich meine Projekt auch entsprechend refrakturiert,  damit bei Vorträgen die Zuhörer sich nicht wundern, warum mein ViewModel nur Model heißt und mein Model -> Datenbankinterface...

Aber wie gesagt, es war schon immer ein MVVM-Pattern.

Für mein Verständnis war eine View ein Form, ein Viewmodel die Formlogic und das Model die Formdatenschicht. Auch wenn es das nicht ganz trifft, sind für einen Delphianer diese Begriffe verständlicher.

Doch spätestens, wenn man feststellt, dass eine Form auch mehrere View's und jede View auch Unterviews haben kann, stellt man doch fest, neue Begrifflichkeiten müssen her.
Also kann man auch direkt die "offiziellen" nehmen.

Aber man braucht nur mal zu googlen... Es gibt viele Leute die nach dem gleichen Motto  programmieren. (Auch wenn es jeder ein bisschen anders macht).

Einfach mal beim nächsten Programmierer Treffen in die Runde Fragen:

- Wer erzeugt die View?
- Wer erzeugt das Viewmodel?
- Darf die View Code enthalten?
- Darf die View das Viewmodel kennen?
- Wer räumt den Speicher wieder auf?
- Wer schließt die Form?

Und schon ist der Ärger vorprogrammiert und die Hartliner (also die Oberschlauen, die mit dem Patternbuch unter dem Kopfkissen schlafen gehen) müssen jedem der es nicht hören will, die einzig richtige Lösung aufschwatzen...

Immer schön geschmeidig bleiben....

Für mich gelten nun folgende Regeln:

1. Form -> also die MainView -> View first -> wenn von der Application erzeugt, wird das MainViewModel drangehängt.

Alle anderen View's sind ViewModel-first... Die View wird über eine Viewlocator erzeugt und das Model wird per Constructor Injection dem ViewModel übergeben (oder holt es sich per Factory aus dem Pool).

Meine View's kennen Ihr Viewmodel. (Property's des Viewmodel werden einem Binder übergeben, damit die View darauf zugreifen kann.

Meine ViewModel kommunizieren per multicast Event mit den Views.

Models sind immer interfaces.

Das ganze Boilerplate-Code ist natürlich im FDK, somit kann ich mich auf das wesentliche konzentrieren.

No comments:

Post a Comment