Genau, entscheidend ist, dass man die Dateien der partiellen Klassen entsprechend logisch benennt. Weil dann hat es ja wieder Struktur, wenn man direkt am Dateinamen erkennt, welche Teile der Klasse dort drin stecken (und natürlich dann auch nur diese Code-Teile in die entsprechende Datei packt).Tornhoof schrieb:
C# GUI wird zu groß
- Ersteller Ghost_Rider_R
- Erstellt am
- Registriert
- Nov. 2009
- Beiträge
- 795
Also ich habe mir das MVVM-Konzept jetzt einmal angesehen. Zuerst einmal Ja, es funktioniert und man bekommt seinen Code auf ganz wenige bis fast gar keine Zeilen Code reduziert. Bis dahin ist erstmal alles gut.
Was mich aber massiv stört ist der dadurch entstandene Mehraufwand. Man muss hierzu jede einzelne Property auslagern und das kostet doch sehr viel Zeit und macht einen sehr langsam bei der Entwicklung. Habe ich z. B. ein Textfeld, dann müsste ich je nach Anforderung z. B. den Inhalt in eine eigene Property auslagern, ob er Enabled ist oder nicht in eine eigene Property, eventuelle Events etc.
Das ist für mich in Summe das größere Übel als eine große GUI-Klasse. Eventuell gehe ich dann doch den Weg über die partiellen Klassen...
Was mich aber massiv stört ist der dadurch entstandene Mehraufwand. Man muss hierzu jede einzelne Property auslagern und das kostet doch sehr viel Zeit und macht einen sehr langsam bei der Entwicklung. Habe ich z. B. ein Textfeld, dann müsste ich je nach Anforderung z. B. den Inhalt in eine eigene Property auslagern, ob er Enabled ist oder nicht in eine eigene Property, eventuelle Events etc.
Das ist für mich in Summe das größere Übel als eine große GUI-Klasse. Eventuell gehe ich dann doch den Weg über die partiellen Klassen...
Na ja, alles was du als public im Model hast, machst halt ein {get;private set;} hinten dran, wenn es modified wird, ein {get=>field;set{field=value;RaisePropertyChanged();} . Und wenn du komplizierte Enable Regeln hast, dann schau dir mal Converter an (z.B. den klassische BooleantoVisibilityConverter).Ghost_Rider_R schrieb:
Das Spannende an der Sache ist die, dass du oft eigentlich ein sehr simples Model hast, das du dann nur noch "Rausrendern" musst. Quasi MVC, bloß ist V und C halt doch oft die gleiche Entity. Zusammen mit z.B. dann <ItemsSource> und XAML Resources kannst du dann z.B. eine Liste von verschiedenen Dingen dynamisch anzeigen und bearbeiten.
Was mir fehlt: Annotation, dass beim set auf eine Property ein PropertyChanged ausgelöst werden soll, das muss ich so oft schreiben (VS macht das direkt mit Autocomplete, ist also nur 2 TAB entfernt).
Weitere Vorteile: Durch die saubere Kapselung kann man direct Hibernation mit z.B. JSON machen, ne API anbieten usw.
Genau das bekommst du mit MVVM Toolkit über die Source Generatoren. Da nutzt man bei den Properties und Commands einfach Annotation und anhand dessen wird dann intern der entsprechende Code generiert. Im eigenen Quellcode steht aber weiterhin nur die Annotation.Hancock schrieb:
https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/generators/observableproperty
