Kann man MVVM mit Windows Forms verwenden?

Hi group,

ich versuche mich gerade in MVVM einzuarbeiten, als Vorbereitung auf ein Xamarin.Android Projekt.
Zu Begin hätte ich jetzt erst mal mit einem Windows Forms Projekt damit herumgetestet/gespielt, da ich WinForms am besten kenne.

Aber geht das überhaupt?
Kann man MVVM mit WindowsForms umsetzen oder hat da das .NET Framework zu viel in einer Formklasse integriert und verhindert so die Trennung der View?

Gruß as

Hallo aschenk,

MVVM passt am besten zu WPF -- siehe z.B. Das Model-View-ViewModel (MVVM) Entwurfsmuster für WPF

Bei WinForms kannst du die View am ehesten per MVC entkoppeln, wobei hier der Controller die Summe der Ereignishandler ist. Wenn also in den Ereignis-Handler die Aktionen an "Services" weitergereicht werden, so kann die View sehr gut von der Logik entkoppelt werden.

Es gibt zwar Anpassungsversuche von MVVM für WinForms, aber das entspricht auch weitestgehendst dem Ansatz von MVC bei WinForms, nur mit anderer Bezeichnung.

Siehe ggf. auch [Artikel] Drei-Schichten-Architektur

mfG Gü

Ich muss da gfoidl, doch ein wenig wider sprechen.

Erst mal zu den Grundlagen der Pattern.

MVC hat eher V förmige (b.z.w. Umgekehrtes V je nach Darstellung) Abhängigkeiten. Der Controller kennt Model und View und beide kommunizieren mit Events mit dem Controller.

MVVM hat eher eine liniere Abhängigkeit. View kennt ViewModel und das kennt das Model. Nach oben wird mit Events kommuniziert.

Mehr sagen beide Pattern erst mal nicht aus (Hohe Abstraktion).

Sowohl MVC als auch MVVM können beide mit WPF und Windows Forms umgesetzt werden. Der unterschied ist, das WPF direkt für MVVM konzipiert wurde und ich so mit keinem/wenig Codebehinde auskomme. Bei Windows Forms werde ich noch Codebehind brauchen.

Meines Erachtens ist es kein Problem mit Windows Forms MVVM umzusetzen, außer das es im Codebehinde ein wenig mehr Aufwand bedeutet als bei WPF. Zu MVC sehe ich da keinen Nachteil, sondern eher sogar Vorteile. Wenn ich bei einen Windows Forms Projekt MVVM verwende, kann ich in Zukunft einfacher auf WPF umsteigen und meines Erachtens ist MVVM auch leichter mit Unit/Integrationstest zu Testen als MVC.

Zur Umsetzung vom MVVM mit Windows Forms gibt es bei Google viele Beispiel und auch einig „Frameworks“, die muss man sich einfach mal Anschauen.

Vielleicht nach zur Abgrenzung. Weder das MVC noch das MVVM Patter enthalten in ihrer Abstraktion so Sachen, wie Daten Laden/Speichern oder Businss Logik. Hier kommen dann noch meist andere Pattern mit ins Spiel. Das geht dann aber schon eher in Richtung Implementierungsdetails. Und selbst beim MVVM Pattern gibt es, da mehrere sinnvolle Ansätze.

Mir Persönlich gefällt der Ansatz gut, bei dem das Model mehr oder weniger einer reine Datenhaltungsklasse ist (was bei DDD schon wieder ein Antipattern ist, da es dann ein Anemic Domain Model ist) und das VM die BL kennt (z.B. über einen Service) und der BL den DAL.
Ist aber Geschmackssache und kommt natürlich auch auf die Anforderungen an.

Meines Erachtens gibt es nicht einfach den Weg, sondern es führen viele Wege zum Ziel. Und wenn man für sich den Richtigen finden will, muss man sich einfach mal ein paar unterschiedliche Anschauen und dann entscheiden welcher für einen der Richtige ist. Da hilft es wenn man die Grundlagen (über der OOP) verstanden hat. Das würde aber den Rahmen des Beitrag sprengen, deshalb einfach mal ein paar Suchbegriffe (Rechtschreibfehler können enthalten sein und die Liste ist sicher nicht Vollständig).

SOLID-Prinzipien
KISS
DRY
YAGNI
Antipattern
TDD (Test Driven Develobment)
CCD (Clean Code Development)

.. im Endeffekt also nur die ausführlichere Variante von gfoidls Antwort und kein Widerspruch 😃

@Abt ich wollte ja auch nur ein bisschen Wiedersprechen. Um mal die Punkte hervorzuheben.

Bei WinForms kannst du die View am ehesten per MVC entkoppeln, ...

Geht genau so gut mit MVVM. Ich sehe da jetzt keinen Vorteil beim MVC Pattern, eher Nachteile.

Es gibt zwar Anpassungsversuche von MVVM für WinForms, aber das entspricht auch weitestgehendst dem Ansatz von MVC bei WinForms, nur mit anderer Bezeichnung.

MVC und MVVM sind sich zwar sehr Ähnlich, der Grundlegend Unterschied ist aber wer wenn „kennt“. Und wenn ich MVVM mit Windows Forms umsetze, statt mit MVC ändert sich im wesentlichen genau das. Der Controller (VM) kennt nicht mehr die View. Sonder die View das ViewModel (Controller).
„V Förmige“ Abhängigkeiten ändern sich in Lineare.

Argumente wie "geht genauso" hinken ziemlich; denn "gehen" tut erstmal alles - alles nur eine Frage des Aufwandes.
Der Aufwand von MVVM in WinForms ist aber deutlich höher als MVP oder MVC.

Aufgrund des Aufwandes und der Tatsache, dass die wenigsten MVVM nach Lehrbuch machen, empfehle ich persönlich i.d.R. bei WinForms eher MVP als MVVM.

Die eigentliche Empfehlung - und das stört mich ein wenig an Deiner Argumentationsbasis, deren Kernaussage eigentlich "MVVM ist das Beste!!!" zu sein scheint - kommt es drauf an, was er machen will.
Es gibt auch bei WinForms Fälle - aber in meinen Augen wenige - bei denen MVVM praktischer ist als MVP/MVC.
Andersrum ist MVVM bei WPF i.d.R. das am Effizienteste.

Also das der Aufwand für Windows Forms bei MVVM höher ist als bei MVC oder MVP sehe ich nicht. Meines Erachtens läuft es grob auf den selben Aufwand hinaus. Aber wenn der Aufwand bei MVVM deutlich höher ist, kannst du es ja sicher belegen.

Das bei WPF der Aufwand geringer ist als bei Windows Forms ist klar.

Auch habe ich nicht einfach eine Kernaussage getroffen, wie "MVVM ist das Beste!!!". Sondern begründet wie so ich es meiner Meinung nach so umsetzten würde (Kompatibilität zu WPF und besserer zu Testen). Zusätzlich habe ich, ja dann noch angegeben, das es nicht den einen Weg gibt, sondern viele. Und dazu noch ein paar Begriffe angegeben, nach denen man mal googeln sollte.

Was meines Erachtens deutlich weitergeht, als was du zu einem Service Tier (Tier nicht Layer) in einigen deiner Beiträge geäußert hast. Ein zusätzlicher Tier bietet durchaus Nachteile, die man auch mal äußern sollte.

p.s.
Sollte das jetzt eine Diskussion werden. Bitte nach meine 1. Beitrag abtrennen.

Hallo,

Muster sind nur dazu da einen Leitfaden zu haben und nicht deshalb damit diese 1:1 nachgebaut werden.
Konkret geht es bei dieser Art der Architektur-Muster um eine Trennung von Anzeige (View) und Logik (~Model).
Je nach Framework-Unterstützung kann dies per Daten- und Command-Bindind geschehen. Falls kein Command-Binding vorhanden ist, so kann der Weg über Code-Behing (the View) bzw. Ereignishandler geschehen.

Ob die View nun an ein Presentationmodel od. ein Viewmodel gebunden wird spielt (für mich) ebenfalls eine untergeordnete Rollen, denn hauptsächlich sind dies nur zwei Namen für das Kind. Aber mit dem selben Ziel -- die Entkopplung.

Auch verschwimmt in gewissem Maße die Grenze zwischen MVC, MVP und MVVM, je nachdem wie das Muster tatsächlich umgesetzt wird (und auch wie die Umsetzungmöglichkeiten seitens verwendeten Framework sind). Siehe einleitenden Satz.

Ich erachte den Sinn hinter diesen Mustern (siehe [Artikel] Drei-Schichten-Architektur) wichtiger als die treffende Bezeichnung zu finden.

Um auf die ursprüngliche Kernfrage

hat da das .NET Framework zu viel in einer Formklasse integriert und verhindert so die Trennung der View?

zurückzukommen: WinForms bietet vom Framework her weniger Möglichkeiten die View per Bindings zu entkoppeln, daher der Weg über die Ereignishandler, aber die View kann gut entkoppelt werden.

mfG Gü