MVVM Umsetzung mit WinForms

Coldfire schrieb:

ist die Verwendung von WinForms als Viewmodell als Strategie zu teuer?

Das ergibt jetzt keinen Sinn, daher ignoriere ich das mal.

Coldfire schrieb:

Mein Argument pro MVVM wäre die Vermutung, dass es einfacher automatisierbar ist.

Was meinst Du konkret mit automatisierbar? Sie sind - wenn man Models und ViewModels richtig gestaltet - automatisierbar testbar. Stichwort TDD (Also Test Driven Development, nicht Typed DataSet Driven Development )
a) nein, es wird umfangreicher
b) wenn man einmal den Durchblick hat, ist es besser als Spaghetticode - Übungssache
c) durch automatisierte Tests: ja
d) ja, da Codeprinzipien à la Clean Code noch besser eingehalten werden können - wenn man sie denn anwendet
e) dito
f) wenn man erstmal geblickt hat, dass es eigentlich recht simpel ist, bleibt es das auch; was hab ich mir nen gedanklichen Abriss mit WPF und MVVM gemacht, bis ich geblickt habe, worum es einfacherweise wirklich geht …
g) Wenn Models und ViewModels unabhängig vom View sind, ist man damit flexibler als mit einer ClassicWinForms-App: Das View ist ja austauschbar, kann also ne WPF-App, WinForms-App, Konsole, sonstewas sein. Aber plattformunabhängig? Keine Ahnung.
h) Für ne 08/15-App, die auf eine Bildschirmseite passt, ist MVVM Overkill.

Warum macht man WPF-Apps im MVVM-Stil? Warum nicht klassisch CodeBehind? Und die gleiche Doppel-Frage kann man bei WinForms genauso stellen. Für mich ist MVVM auch eine Möglichkeit, mehr über den Code nachzudenken, ihn sauberer zu gestalten und Dinge zu trennen, die nicht zusammengehören. Ich könnte auch alles in eine Form-Klasse und am besten noch alles in die EventHandler schreiben. Zurück ins Chaos meiner Anfangsjahre. Aber das ist natürlich Nonsens. Stattdessen: Aufräumen, Struktur schaffen, Dinge dorthin räumen, wo man sie wiederfinden und ggf. anpassen oder abändern kann. Das ist das Ziel und MVVM ist ein Weg dorthin. Ich sehe immer noch so viele Apps bei mir, bei denen in den Formklassen so viele Dinge geschehen, obwohl es einfach nicht die Aufgabe der Forms ist, sich um diesen Kram zu kümmern. Es sind IO-Klassen, Benutzerdaten rein, Anzeige raus! Und mehr nicht. Keine Berechnungen, keine Daten laden oder speichern, usw. usf. Es ist einfach nicht deren Job, sich um was anderes zu kümmern, als die Daten weiterzugeben (ans ViewModel oder an den Monitor) und das will ich zumindest beherzigen und umsetzen, Stichwort SRP.

Amelie schrieb:

Ich finde es äußerst verwirrend, wenn Code der in VS2017 / VS2019 noch funktionierte dann in VS2022 nicht mehr geht... Erwähnt ich hier auch schon, bzgl der Singelton Class ...

Bei mir wird das nicht mit der Singleton-Klasse angezeigt. Mach mal bitte n Screenshot von der VS-Meckerei.

@Coldfire: Jo, das ist ja ein nettes Sortiment an Fragen. Die meisten Fragen verwenden den Komparativ. Dabei bleibt ungesagt, gegen was der Vergleich angestellt werden soll. Wenn gegen den Pattern "Alles ins CodeBehind" verglichen werden soll, so muss man für banale Programme die meisten Fragen verneinen, aber ab einer gewissen Komplexität (ungefähr mehr als 1 Form/UserControl, bzw mehr als 500 Zeilen) wird MVVM günstiger, und ab mittelgrosse Anwendung kommt man mit "Alles ins CodeBehind" ja garnet mehr zurande.
Aber ich lege dir meinen CodePattern vor, der sich bei mir seit ca. 10 Jahren herauskristallisiert: "Dataset driven Development" habich das genannt, "DDD".
Das löst dieselben Probleme, die MVVM zu lösen versucht, in Wpf mit Erfolg, in WinForms - naja, unter unverhältnismässigem Mehraufwand.
Also Vergleich WinForms-MVVM - DDD:

a) ist der Code dadurch übersichlicher / einfacher?
nein, DDD ist deutlich übersichlicher / einfacher
b) ist die Wartbarkeit besser ?
nein, DDD ist deutlich besser wartbar
c) ist die Implementierung der Funktionalitäten damit weniger fehleranfällig ?
da liegen sie wohl gleich, aber in MVVM ist schwieriger sich zu orientieren
d) ist die Erweiterbarkeit des Codes dadurch besser ?
wohl gleich
e) geht das Implementieren schneller?
DDD ist deutlich! schneller
f) wie hoch sind die Lernhürden (Dichte und Anzahl der Fachbegriffe, die die Erlärungen spicken) ?
DDD basiert auf typisiertem Dataset, und das basiert auf relationaler Datenmodellierung.
mit MVVM kann man sich beliebige Datenmodelle zurechtwursteln, und gelegentlich schön auf die Nase fallen.
Dann wird man auch für MVVM relationale Datenmodellierung erlernen müssen - sie allerdings umzusetzen ist nicht in jedem Falle möglich.
Also beim MVVM-Lernen kann man an relationaler Datenmodellierung "vorbeirennen", was einen aber böse einholt.
MVVM hat einen Haufen eigenen Lernstoff, allerdings recht schwammig, "was ist/darf viewmodel?, was ist/darf model?, und was für Hilfs-Konstruktionen müssemer auffahren, um am Ende dennoch zu erreichen, was die Anwendung tun soll?
Das typDataset hingegen ist eine klare Sache: Man bastelt sich eines, dann kann man es untersuchen, und seine Eigenschaften kennenlernen.
g) wie sieht es mit der multiplattformunterstützung aus ?
äh - WinForms? mau.
h) gibt es Einschränkungen, die die Implementierung unmöglich machen bzw ad absurdum führt ? (spezielle Controls,..)
Wie gesagt: Für Winz-Anwendungen lohnt sich das nicht.
DDD lohnt sich, sobald eine Liste von Daten abzuspeichern und zu laden ist
MVVM lohnt sich erst bei komplexeren Anwendungen.

Übrigens, Testbarkeit: Ein typisiertes Dataset (inklusive aller Erweiterungen, die DDD ihm "antut") ist ebensogut unit-testbar wie ein ViewModel.

@Coldfire Das MVVM ist relativ gut verbreitet, das spricht doch für ein Paradiga. Wie gesagt laue Ideen sind wenig bekannt. Da kann jeder ja individuell prüfen, ob es seinem Geschmack entspricht, aber eine objektive Bewertung vornehmen muss nicht jeder machen, das hat keinen Mehrwert.

Amelie schrieb:

Brauche ich für die Durchschnittswerte denn ein Model ???

Nein. Welche Klasse weiß von allen ClimaModels? Jene Klasse darf gerne auch die Berechnungen durchführen und sie dem View zur Verfügung stellen. Das kann also m.E. gerne ins MainViewModel. Denn andere ViewModels werden zwar vielleicht auch die Rohdaten verwenden. Aber nicht auf jedem View wird die Durchschnittstemperatur benötigt.
ClimaModel … die Benennung find ich ausbaufähig. Dass da was modelliert wird und ein digitales Abbild von einer realen, wenn auch abstrakten Sache geschaffen wird, muss sich nicht im Namen widerspiegeln. Das ist eine Redundanz. Aber was wird modelliert/digitalisiert? Ein Clima? Nee, eigentlich eine Messung, also quasi Measurement oder spezifischer WeatherMeasurement. Aber es ist Dein Kind und Du kannst es benennen, wie Du willst.

Ein separates VM? Bedenke, dass das VM unter anderem dazu dient, Daten mindestens eines Views aufzubereiten. Zwei VMs für ein View ist m.E. Murks. Das kann bedenkenlos inst MainViewModel. Und ob Du für die Berechnungen ne eigene Partial File verwendest: Warum nicht? Mach ruhig, wenn es Dir bei der Übersicht hilft.

Noch nicht. ich hab grad zu wenig Zeit und melde mich wohl diesbezüglich morgen. Für die Analyse eines fremden Projektes reichen mir keine 10 Minuten.

##########

@Amelie:
Folgende Klassen im Ordner Models haben komische Namen: CreateTemplate, LoadDataSet, SaveDataSet. Das sind eher Methodennamen. Außerdem gehören sie eher in den Ordner Varios. Inhaltlich gehören SaveDataSet und LoadDataSet zusammen in eine Klasse.
ClimaModel - ja, das ist eine Modelklasse.
Bei AvgClimaModel hatte ich ja schon die Frage beantwortet, dass die Klasse nicht nötig ist.

Configuration ist auch eine Modelklasse
Ist ConfigViewModel absichtlich nicht im Ordner ViewModels?
SaveLoadConfigModel würde auch in Varios gehören, aber vielleicht hast Du die ganzen ConfigSachen auch absichtlich in einen eigenen Ordner geschoben.

FrmMain kennt das ConfigViewModel. Wozu? Es wird nicht in der Klasse benötigt oder darauf verwiesen.
Das ist MVVM-mäßig mit DataBinding umzusetzen.

plus der meiste Code in FrmConfig: Puh, Du sträubst Dich aufgrund des BindingBugs echt gegen den Einsatz einer Designer-BindingSource, oder?

andere Sachen
Wozu das Setzen von Nothing?

Warum nicht einfach Close?

Wozu EndEdit? Das Verlassen des DGVs durch Klicken eines Buttons etc beendet automatisch den Bearbeitungsmodus des DGVs.

Amelie schrieb:

Ohne dem wurde aber nichts gespeichert!

Da hast Du recht. Da verhält sich ein ToolStripItem leider anders als ein Button. Das hatte ich bei meinem Test nicht beachtet. Der EditMode wird beim ToolStripClick tatsächlich nicht verlassen, weil der Eingabefokus nicht verloren geht.

Amelie schrieb:

Bevor mir wieder und wieder immer alles "verloren" geht, mache ich es halt so.

Leider zählt dieses Argument nicht, solange Du ein .NET-Fx Projekt hast In .NET-Apps gibt es den Bug noch, aber Du hast ja schon ne Weile Dir ein .NET-Fx-Projekt angelegt. Da hab ich das Problem noch nicht feststellen/nachbauen können. Probier es einfach mal in einer Testapp mit .NET-Fx 4.5 oder 4.8.

Das mit der Sortierung solltest Du dann aber etwas vereinheitlichen, weil Du einen Ordner ViewModels und Models hast und dann eben noch Config, wo Du dann aber spezifische Models und ViewModels drinhast.

Amelie schrieb:

Vielleicht brauche ich da da nochmal????

1. nein, da das ConfigViewModel nichts im MainView zu suchen hat, genauso wie grundsätzlich Viewfremde ViewModels nicht auftauchen sollten.
2. Für den Fall, dass Du es glaubst, es wirklich zu brauchen: Bau es dann ein, wenn es wirklich soweit ist und frag Dich/uns vorher, ob das zu lösende Problem besser lösbar ist. Ich kann keinen Grund bisher finden, ViewModelX in ViewY zu haben.

Amelie schrieb:

Hab mal irgendwo gelesen, soll besser sein als nur Close.

Wenn Du ne Quelle hast, immer her damit. Da Deine App so gebaut ist, dass das Programm beendet wird, wenn das MainForm geschlossen wird, brauchst Du Dich nicht explizit um das Aufräumen zu kümmern. Außerdem finde ich die Aussage von Microsoft jetzt nicht so dolle:

Microsoft schrieb:

Die Exit-Methode beendet alle ausgeführten Nachrichtenschleifen in allen Threads und schließt alle Fenster der Anwendung. Diese Methode erzwingt nicht unbedingt das Beenden der Anwendung.

Application.Exit könnte man verwenden, wenn man von irgendeiner Stelle im Code das Programm beenden will. Aber sowas hab ich noch nicht benötigt. Der normale Werdegang ist ja, dass man alle Forms schließt, wenn man die ganze Zeit mit ShowDialog alle SubForms kreiert. Würde man mit multiplen gleichberechtigten Forms arbeiten, also mit Show statt mit ShowDialog, ist es schon eine Option, dass man auf einem oder mehreren Forms die Option haben will, die ganze App zu schließen. Aber sowas hast Du ja nicht. Du hast ein MainForm und die anderen Forms erzeugst Du mit ShowDialog. Daher ist Application.Exit bei Dir überflüssig.

Kommt da noch was oder hast Du Dich (hoffentlich nicht schon wieder) verheddert?