Das ergibt jetzt keinen Sinn, daher ignoriere ich das mal.Coldfire schrieb:
ist die Verwendung von WinForms als Viewmodell als Strategie zu teuer?
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 DevelopmentColdfire schrieb:
Mein Argument pro MVVM wäre die Vermutung, dass es einfacher automatisierbar ist.
![;)](https://www.vb-paradise.de/wcf/images/smilies/wink.png)
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.
Bei mir wird das nicht mit der Singleton-Klasse angezeigt. Mach mal bitte n Screenshot von der VS-Meckerei.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 ...
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.
Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()