Hallo zusammen,

die von @Yanbel angestoßene Diskussion bzgl. MVVM@WinForms hat mich zum Schreiben dieses Threads geführt. Ich möchte explizit seinem geplanten Thread nicht vorgreifen. Da ich allerdings keine Ahnung habe, was kommt, ich aber auch nicht weiß, wann es kommt, folgt hier eine kleine WinForms-Architekturdesignentwicklung, die der ein oder andere, der vielleicht genauso fachfremd wie ich ist, als Anleitung sehen könnte, etwas besser sein eigenes Projekt zu strukturieren oder neue Möglichkeiten gezeigt zu bekommen. Dazu habe ich erstmal fünf Entwicklungsstufen eines Projekts erzeugt. Für Pros und alte Hasen dürfte dieser Thread aber wahrscheinlich wenig interessant sein.
Das eigentliche Projekt, welches in seinen 5 Stufen hier beschrieben wird, befindet sich als Gesamtpaket im Anhang und ist an sich lächerlich. Es ist ein einfaches Pseudowürfelspiel gegen den Computer und bedarf keiner Erklärung. Auch die verwendete Lade-/Speichertechnik für die Statistik ist ein Witz. Aber genau dabei soll es auch bleiben, um den Fokus auf den Umgang mit dem Formular (im Weiteren kurz das(!) Form, denn das ist auch der englische Begriff für Formular, daher WinForms) an sich zu behalten.


Stufe 1 - Einsteigerart

So würde es wohl ein Programmiereinsteiger machen.
Das Form weiß alles. Alle Variablen sind formweit bekannt. Keine Klasse außer Form. Die ganzen Abläufe sind in den EventHandlern der Buttons untergebracht.

Vorteile

• Man kann direkt alle auf dem Form anzuzeigenden Texte und andere GUI-Veränderungen vornehmen.
  
• Der Code ist sehr kompakt (im Vergleich zu den anderen Ausbaustufen).
  
• KISS - zumindest für den Anfang
  

Nachteile

• Verletzung von SoC, SRP, DRY und zweifellos anderen Prinzipien auch.
  
• Testbarkeit? So ziemlich unmöglich.
  
• Der Anfang vom Spaghetticodechaos, in den man sich irgendwann als Codeanfänger verfängt, nie mehr rausfindet und deshalb früher oder später frustriert aufgibt.
  

Stufe 2 - Klumpenform

Immer noch ist das Form der Oberboss. Es hat zumindest mal eine weitere Klasse in den Code geschafft, auch wenn es nur minimal besser als Stufe 1 ist.

Vorteil

• Zumindest gehören die Spielvariablen nicht mehr zum Form direkt, sondern in eine Klasse, die dafür auch verantwortlich ist.
  

Nachteile

• siehe Stufe 1
  

Stufe 3 - Klassennutzung

Die erste Klasse wurde stark ausgebaut, die Spielmechanik (alias Business Logic?) steckt nun in ihr. Auch das Speichern und Laden ist in eine eigene Klasse gewandert, wurde also vom Rest abgespaltet.
Ich habe auch absichtlich Aufrufe der Art EventHandler->Integration->Operation drin. Im BtnThrowDice.Click-EventHandler wird erst ThrowDice aufgerufen, was wiederum Game.ThrowDice() aufruft.


Vorteile

• Plötzlich sieht man, was wo passiert und welche Klasse wofür konkret verantwortlich ist. Das Speichern und Laden soll geändert werden? Dafür ist die Klasse GameFileContentManager nun verantwortlich. Es sollen weitere Würfel hinzukommen? Man ändert die Game-Klasse.
  
• für CCD-Fans: IOSP ist an dieser Stelle viel einfacher umzusetzen
  
• Man kann mit Partial files nun viel besser trennen: geht es um EventHandler? Will man nur Prozeduren anschauen, die das GUI manipulieren? Oder ist man nur an Validierungsfunktionen interessiert? Da kann man sehr gut eigene Aufteilungen der Klassen angehen, wo vorher nur Mischmasch-in-Prozeduren war. Dies ist zwar nicht erst durch die hier eingeführte Klassennutzung möglich, aber es geht einfacher, da nun eine Monolithenklasse selber aufgeteilt wird.
  

Nachteile

• Der Code wird plötzlich gefühlt 3x so groß, bedingt durch gegenseitige Aufrufe und viele Prozedurrümpfe.
  

Stufe 4.1 – MVP Oberbossform

Keine Ahnung, ob die Stufe 4 das ist, was man als eine Art von Model-View-Presenter bezeichnet, aber es klingt ein wenig nach dem (nicht vollständig! das Model weiß bei mir nix von ViewModel und Form!), was man Martin Fowler unter der Bezeichnung Supervising Controller zuschreibt, glaubt man dem Wikipedia-Eintrag.
Das Form bleibt weiterhin Oberboss, erzeugt aber eine ViewModel-Instanz, welches sich um den Kontakt zur Spielmechanik kümmert. Das Form selber sendet Befehle ans ViewModel, welches diese dann umsetzt. Werden GUI-Updates benötigt, teilt das ViewModel dies über Property-Änderungen und dem EventRaising von PropertyChanged (als Implementierung der INotifyPropertyChanged-Schnittstelle) mit, wodurch eine BindingSource auf dem Form dies an die einzelnen GUI-Elemente weitergibt. Für jede GUI-Property-Änderung wird also quasi eine Klassenproperty im ViewModel benötigt. Will man auch z.B. Texteingaben aus einer TextBox ans ViewModel weiterleiten, muss man natürlich die Private Setters in Public Setters umwandeln.

Vorteile

• Das Form macht fast nichts mehr, nur noch das Weiterleiten der Eingaben an das ViewModel. ViewModel-Properties sind über eine BindingSource mit dem GUI verbunden.
  
• Das ViewModel bleibt bei einer Aufgabe: Sich um die Koordinierung des Datenmodell zu kümmern. Indem es selbst seine Daten ändert und eventuelle Änderungsevents feuert, ist es ihm egal, wer damit was anfängt. Das ViewModel weiß damit nichts über das Form.
  

Nachteile

• Für jede Property, die man auf dem GUI ändern will, braucht es eine eigene ViewModel-Property. Und zwar allein wegen des Event-Feuerns komplett ausformuliert – zumindest bis Microsoft sich da was einfacheres überlegt. Zum Glück kann man die in ne Partial-Class-File auslagern oder notfalls in einer Region verstecken.
  

Stufe 4.2 – MVP Passivform

In dieser Ausbaustufe wird das Form komplett zur Anzeige degradiert. Das ViewModel übernimmt die Änderungen am GUI. Dies wird dadurch erreicht, dass man in den Projekteigenschaften das Anwendungsframework deaktiviert, Sub Main als Startprozedur einstellt, ein Modul erstellt und dort eine Sub Main definiert, die das ViewModel als Oberklasse bestimmt, welches wiederum das Form aufruft.

Vorteile

• Das Form ist nur noch für eine Sache zuständig: GUI-Design. Keine BindingSource, keine Events.
  
• Das ViewModel kann das Form direkt manipulieren, ohne dafür eigene Properties hernehmen zu müssen.
  

Nachteile

• Man muss jedes Event des Forms, an dem man interessiert ist, per AddHandler abonnieren und beim Beenden am besten wieder abbestellen. Eine Verwendung der Handles-Klausel ist nicht möglich.
  
• Das ViewModel hat eine weitere Aufgabe bekommen (für die SRP-Puristen)
  

Wie geht’s weiter? Ich habe keine Ahnung, da ich Stufe 4 noch nie praktisch außerhalb des hiesigen Demoprojektes angewendet habe. Jetzt sind Eure Erfahrungen und Tipps gefragt. Zweifellos kommen zahlreiche Anmerkungen, Einsprüche, Bedenken, whatever. Ich stehe bezüglich des Umgangs mit der Rolle des Formulars vor neuen Unbekannten. Dies soll auch weniger ein abgeschlossenes Tutorial von mir als ein erster Schritt in eine eventuell gemeinsame Weiterentwicklung prinzipeller Art v.a. für Programmieranfänger sein. Das Projekt an sich soll natürlich nicht weiterentwickelt werden, das kann jeder selber machen. Es geht mir um die Architektur bzw. um die Rolle des Formulars an sich.

##########

Update 18.06.: Im Projekt MVP Oberbossform hatte sich noch ein wenig an Testcode befunden, der da nicht reingehörte.

Stufe 4.3 - MVP PluginForm

Dies ist eine Variante, die dem Programmstart bei 4.2 ähnelt, aber die Beziehung von Form und ViewModel nahezu aufhebt. Das Form macht sich hierbei quasi komplett austauschbar, wohl ähnlich dem, was @mrMo in Post#2 beschreibt.
Während bei den anderen 4er-Stufen entweder das ViewModel Besitz des Forms oder das Form Besitz des ViewModels ist, existieren hier beide Komponenten auf gleicher Ebene. Der Aufbau in dieser Stufe gibt einen ersten rudimentären Einblick in die Prinzipien "Dependency Injection" und "Code against Interface" und Beachtung von new is glue. Beide werden vom Startmodul erzeugt und in Wechselwirkung gebracht.

Wie bei 4.2 kennt das ViewModel das Form, allerdings nicht direkt, sondern das ViewModel weiß nur, dass ihm da ein Ding untergeschoben wird, welches bestimmte Kriterien erfüllt. Darauf kann sich das ViewModel verlassen. Was das Form zur Erfüllung der Kriterien macht, ist dabei dem ViewModel egal.

Beim ViewModel selbst hat sich vom Code im Vergleich zu Stufe 4.2 fast nichts getan. Statt das Form direkt zu manipulieren, werden nun die Interface-Methoden aufgerufen. Die grundsätzliche Code-Struktur ist aber die gleiche.
Das Form hat ein paar mehr Aufgaben als bei 4.1. Schließlich muss das Interface implementiert werden.
Für Einsteiger: Das Interface ist in der Datei IForm.vb: Kein Code, der was ändert, sondern nur eine Auflistung von Dingen, die das Form können muss. Wie das Form diese Punkte umsetzt, steht dann in der Form-Klassendatei.

Hätte ich konsequent weiter umgebaut, wären natürlich auch die anderen Klassen durch Einführung weiterer Interfaces vom ViewModel entkoppelt worden. Da ich aber hier den Blick auf die Rolle des Forms bzw. dessen Zusammenspiel mit dem ViewModel richten will, habe ich die anderen Klassen so belassen. Der diesbezügliche Umbau dürfte auch Einsteigern nicht so schwer fallen, schließlich ist das Beispiel mit dem Form gegeben.

Vorteile

• Form und ViewModel sind effektiv unabhängig voneinander, können also auch unabhängig voneinander entwickelt werden; Solange sie sich beide an den Vertrag (nämlich das Interface) halten, ist alles gut.
  
• Das Form kann auch durch ein anderes (G)UI ausgetauscht werden. Solange das Interface implementiert wird, läuft alles. Es ist dann egal, ob sich dann ein WPF-GUI dranhängt, ein Konsole oder eine internetfähige Kaffeemaschine - sofern sie mit einer .NET-Assembly umgehen können
  

Nachteile

• Man muss sich (endlich) mal Gedanken machen, was das UI wirklich können muss. Das kann eine lange Liste werden. Dann ggf. auch über ISP nachdenken bzw. es anwenden, vor allem, wenn man mehr als eine Klasse hat, die man auf diese Weise einbauen will.
  

Ich habe bei Stufe 1 gesehen, dass ich ein Thema nur minimal angeschnitten habe, ohne es weiter auszuführen: Testbarkeit. Dazu werde ich wohl noch später was schreiben.

Tja, ob jetzt MVP oder MVVM - das hab ich eben selber noch nicht raus. Ich habe MVVM immer aus Unwissenheit mit WPF assoziiert und daher eine entsprechende Benennung hier vermieden. Stellt sich dann natürlich die Frage, wie groß der Aufwand von MVVM in WinForms tatsächlich ist und ob das dann wirklich eine so inakzeptable Hürde wäre, es auch anzuwenden, wie manchmal zu lesen ist. Klar, nicht bei jeder Pieps-Kleinkramanwendung muss man gleich mit MVVM u.ä. kommen. Aber auch dafür ist dieser Thread gedacht. Das Projekt ist klein. Und trotzdem sind wir beim Thema Umsetzung von MVP/MVVM angekommen. Wir könnten ggf. also zeigen/ermitteln, wieviel tatsächlicher Aufwand dafür betrieben werden muss, um es einzubauen/umzusetzen.
Ich hab leider auch mitbekommen, dass ich zwar MVP schreibe, aber nicht von Presenter rede, sondern von ViewModel. Ändern werde ich es aber nicht mehr. Allein schon wegen des hiesigen 1. Abschnitts MVP oder doch eher MVVM?
Bzgl. Supervising Control sehe ich schon viele Sachen in 4.1 umgesetzt und als zutreffend an. Dass der Presenter eben die Daten vom Model über eigene Strukturen an die Ansicht weiterleitet, indem es eben seine PropertyValues verändert und dies per PropertyChanged-Event an die BindingSources meldet, passt doch. Aber wurscht. Wir wollen ja keinen Wikipedia-Artikel diskutieren. Vielleicht ist dort auch die Beschreibung schwammig.

Zu Deinem Beispielprojekt: Aha, vielen Dank dafür. Du arbeitest also nicht nur mit einem ViewModel, welches an das Form per BindingSources in Verbindung steht, sondern mit mehreren, die Model und ViewModel in einem sind, also quasi MVM. Auch ein interessanter Weg. Das Form ist weiterhin Oberboss/Supervising Control. Wenn Du die Kategorisierung erlaubst.

ErfinderDesRades schrieb:

Was mir an deinen Architektur-Darlegungen bisserl fehlt, ist ein Hinweis auf Utilities/Helper-Code.

Nun, mein Hauptaugenmerk liegt ja bei der Rolle des Forms. Dass es einen Haufen Aufgaben übernehmen kann, ist mir bewusst. Aber davon wollte ich ja auch ein stückweit weg. Dass man diese Aufgaben durch Extensions und notfalls Bibliotheksaufrufe kürzen kann: zweifellos.

btw: Dass Du inzwischen bei Property-Settern statt z.B. Set(value As Integer) nur noch Set schreiben musst, weißt Du?

Stufe 4.2 - Passivform ist eine krasse Form-Rolle. Ich wollte dabei nur zeigen, wie ich verstehe, wie man diese MVP-Variante in WinForms umsetzen könnte. Dass dabei dann die ganzen Aufgaben dem ViewModel/Presenter angelastet werden, ist mir bewusst und das habe ich ja auch bei den Nachteilen geschrieben. Mir ging es dabei auch darum, Einsteigern zu zeigen: das Form muss nicht alles können, es geht auch ganz anders - in einer sehr extremen Weise.
Ich persönlich werde zukünftig wohl mein Hauptaugenmerk auf 4.3 und auch etwas auf 4.1 legen. Wie weit ich damit komme, kann ich - wie geschrieben - nicht abschätzen. Aber es sind eben auch Varianten oder Ausbaustufen wie Deine, die Vielfalt die in die Gedankenwelt der (nicht-nur-)Einsteigerprogrammierer bringen (können), um vom Chaos wegzukommen, den die ersten Ausbaustufen früher oder später verursachen.

Nun zum Thema »Nutzung mehrerer Formulare«

Bei den gezeigten Bildern habe ich versucht, die Rechteckgröße proportional zur "Relevanz" einer Sache darzustellen. Relevanz kann aber viel bedeuten:

• Codeumfang
  
• Zeit, wie häufig das Programm in diesem Teil unterwegs ist
  
• Änderungsaufwand
  
• …
  

Allerdings ist mir die Box beim Sub Main ein gutes Stück zu groß geraten



Bei den Kandidaten Einsteigerart und Klumpenform ist es ziemlich einfach. Das Form instanziiert ein weiteres und übergibt die Kontrolle an ein anderes. Wie man vorgeht, hat RodFromGermany ausführlich in Dialoge richtig instanziieren beschrieben.
Wie dabei Verlauf der Kontrolle ist, habe ich mal versucht, schematisch darzustellen:



Bei Klassennutzung und Oberbossform ist fast genauso, nur dass der Datenfluss auch mal in den Klassen bzw. konkret in den ViewModels ist. Trotzdem: Die Erzeugung weiterer Forms und die Übergabe der Kontrolle erfolgt immer noch durch die Forms.



Beim Passivform sieht es schon ein stückweit anders aus. Das Startmodul bzw. die Sub Main übergibt die Kontrolle an das erste ViewModel, welches dann sein Form1 erzeugt. Werden weitere Forms benötigt, erzeugt z.B. ViewModel1 eine ViewModel2-Instanz und übergibt dem die Kontrolle. ViewModel2 erstellt dann wiederum ein Form2, mit dem dann gearbeitet wird usw.



Beim PluginForm ist es komplizierter, aber nahe am Passivformschema dran. Auch hier fließt die Kontrolle von einem ViewModel zum nächsten, indem sie sich instanziieren. Da die ViewModels das UI, mit dem sie zusammenarbeiten, nicht kennen, wird in der Sub Main eine (auch über ein Interface verlinkte) Formfabrik erzeugt und dem 1. ViewModel übergeben. Dieses kann dann die Fabrik anweisen, ein UI zur Verfügung zu stellen, welches dann kompatibel zu den Anforderungen des ViewModels ist. Mit dem wird dann über das Interface kommuniziert (im Schema gelb dargestellt)



das Ganze weitergesponnen:
So kann man mehrere Formfabriken (besserer Name wäre eigentlich UI-Fabriken) erstellen, die eben Konsolen-UIs, WinForms-UIs, … erstellen. Was es dann wirklich wird, wird in der Sub Main entschieden. Und wenn man das dann z.B. noch abhängig davon macht, was in einer beigefügten Textdatei steht, kann man sogar, wenn man das fertige Programm hat, durch Änderung dieser Textdatei entscheiden, was man für UIs bekommt. Vielleicht sind wir dann beim Pattern Abstrakte Fabrik angekommen, aber das geht jetzt zu weit.



Im Anhang habe ich auch noch für die letzten beiden Schemata je ein Testprojekt angehangen, was das bisherige Projekt nur erweitert, damit man nicht gedanklich wieder von vorne anfangen muss, wenn man sich durch die Beispielprojekte dieses Threads durchhangelt.

Stufe 5 - MVVM (As I meant it to be )

Hatte im Vorpost den Code vergessen. Macht nix, war eh eher ein Mischmasch aus MVP und MVVM - Stichwort Kommunikation zwischen VM und View mittels Interface und VM instanziiert das View. Daher nochmal Rolle rückwärts und von vorn:

Das MainForm wird nun in der Sub Main erzeugt und ihm wird als DataContext ein ViewModel mit an die Hand gegeben. In der FrmMain.vb selbst gibt es fast keinen Code mehr. Geblieben ist im CodeBehind nur noch die ViewModel-Zuordnung an eine BindingSource.

Die ViewModel-Klasse koordiniert quasi alles, inklusive einer neu hinzugekommenen Klasse RoundSummary.
Sich verändernde Daten in den Klassen Game und RoundSummary werden mithilfe der INotifyPropertyChanged-Schnittstellenimplementierung an das GUI weitergereicht, sodass dies auf dem aktuellen Stand bleibt. Button-Clicks des UI werden über RelayCommands an das ViewModel weitergereicht, welches dann die eigentlichen Befehle ausführt bzw. diese an die zuständigen Klassen weiterleitet.

Das Form hat somit quasi eine pure Anzeigerolle erhalten, ähnlich wie bei 4.2 MVP Passivform, aber mit m.E. besseren Methoden. Gleichzeitig ist das Form Eigentümer des ViewModels, das ViewModel kennt das Form nicht. Damit ähnelt diese Stufe wiederum 4.1 MVP Oberbossform/Supervising Controller

Einen BourbonWermutstropfen gibt es aber: Das Schließen des MainForms. Das scheint mir auch in WPF-MVVM laut ersten Recherchen ein noch nicht endgültig gelöstes Problem. Mein Ansatz:

• Ich binde in der FrmMain.Designer.vb die DialogResult-Property des Forms an die DialogResult-Property des ViewModels.
  
• Ich starte das MainForm in der Sub Main via ShowDialog.
  
• Ich verwende einen RelayCommand, um die DialogResult-Property des ViewModels und mittels INotifyPropertyChanged auch die gleich benannte des MainForms mit einem anderen Wert zu belegen, was zum Schließen des MainForms und somit zum Programmende führt.
  

Das Ganze hat aber 3 Nachteile:

1. In der Sub Main wird das MainForm nicht klassisch per Application.Run(New FrmMain) gestartet/angezeigt, da ich sonst keinen Dialog erhalte, den ich mittels Setzen des DialogResults automatisch schließen lassen kann.
   
2. Das DataBinding für die Form-Property DialogResult muss manuell in der Form.Designer.vb erfolgen, da diese nicht im Designer selbst beim DataBinding-Dialog zur Verfügung steht bzw. angeboten wird.
   
3. Das ViewModel muss den Datentyp DialogResult kennen, was dazu führt, dass man das ViewModel nicht für eine WPF-MVVM-App nutzen kann, weil dort die Window-Property DialogResult vom Typ Boolean? ist.
   

Für Gegenvorschläge bin ich offen.
Das Einfachste (Stichwort KISS) wäre natürlich im MainForm-CodeBehind ein EventHandler für den ButtonClick und Me.Close. Aber ist das MVVM-gerecht? Schließlich macht das Form jetzt was selbst und das VM macht es nicht.

Schön wäre, wenn andere Vorschläge keinen Code im CodeBehind des Forms benötigen und das ViewModel nicht das MainForm als Parameter nutzt.