Danke 👍. Bin mich gerade in MMV am reinfummeln. Dein Video ist mir eine goße Hilfe. Habe mittlerweile herausgefunden, dass man die Proberties im Model mit Hilfe des vorangestellten Attributts [ObservableProperty] noch schlanker definieren kann. Dadurch muss man nur die lokale Variable definieren, der Codegenerator erzeugt den Rest in einer partiellen Klasse. 😎
Ich habe das mal kurz geprüft. Leider habe ich nur eine Fehlermeldung erhalten, dass die Klasse SimplePerson schon existiert. Ich habe sie dann als "partial" markiert. Und dann funktionierte dies. Vielen Dank. Das werde ich in einem Update zeigen, welches u.a. auch andere Denkfehler aufzeigen wird.
Ich habe die Models und ViewModels gerne in separaten Projekten, da man somit einfach das UI Framework austauschen kann. Man kann dann einfach die bestehenden Projekte mit Models und ViewModels und der Geschäftslogik in das neue Projekt referenzieren und muss somit maximal NUR den UI Code und evtl. noch ein paar UI-frameworkspezifische Services neuschreiben.
Ja, wenn man den Code 1x schreibt, dann ist das gut, ein 2. Mal schreibt man ihn vielleicht noch, aber spätestens beim 3. Mal sollte man darüber nachdenken. Und da ist deine Vorgehensweise natürlich sehr charmant.
Super Video. Ich habe allerdings noch nicht so ganz verstanden, wie es funktioniert, dass, wenn ich eine Klasse habe, die etwas berechnet, dass hier die Daten an das ViewModel übergeben werden und dann diese Daten dann an die Klasse weitergegeben werden. Kann das jemand beantworten?
Also wenn du in der UI-Oberfläche (View) etwas änderst, dann änderst du im ViewModel eine Eigenschaft, die im Prinzip auch nur eine Eigenschaft im Model ist. Da das View, das ViewModel und über das ViewModel auch die Klasse kennt, geht das einfach so. Das ViewModel hat ja eine Instanz des Models selbst und das View hat eine Instanz des ViewModels und somit änderst du durch Eingaben im View automatisch die Klasse im Model.
Wenn du im Model etwas berechnest, dann ändert sich in der Klasse des Models eine Eigenschaft. Was das CommunityToolkitMVVM macht, es nimmt dir eine Menge Arbeit ab. Dazu wird eine Schnittstelle implementiert, die ein Event abfeuert, dass sich eine Eigenschaft geändert hat. Das ViewModel selbst hat das Event abonniert und empfängt dann die Änderung. Rückwärst hat das ViewModel eine direkte Verbindung, weil es selbst eine Instanz des Models also der Klasse hat. Deswegen benutzen wir das CommunityToolkit.MVVM, weil wir sonst richtig viel Arbeit mit der Implementierung von Schnittstellen wie INotifyPropertyChanged, INotifyPropertyChanging usw. haben.
Wenn du einen eigenen Dialog erstellt hast, dann kannst du das folgender Maßen erledigen. Gib dem Window einen Namen über x:Name, dann beim schließen Button nimmst du nicht nur das Command sondern auch den CommandParameter. Darin bindest du das Window, also ungefähr so {Binding Elementname=Name Fenster}. So ähnlich zumindest. Im ViewModel erstellst du ein Relaycommand mit dem Parameter Window. Darin kannst du dann das Fenster schließen. Eine andere Möglichkeit bieten DialogServices. Es gibt noch viele Fragen bei MVVM. Und es gibt auch Stimmen, die sagen, das ViewModel keine Berechtigung haben, man kann auch alles ins Codebehind des Views packen. Und auch hier hat das CommunityToolkit mit den Attributen [ObservableObject] und [ObservableRecipient] in der Window Codebehind Datei eine Möglichkeit.
Zur Info. Microsoft hat mittlerweile das Toolkit verschoben zu CommunityToolkit.MVVM.
Super und sympatisch erklärt. Perfekt zum Einsteigen in WPF. Danke!
Vielen Dank für deine Worte.
Danke 👍. Bin mich gerade in MMV am reinfummeln. Dein Video ist mir eine goße Hilfe.
Habe mittlerweile herausgefunden, dass man die Proberties im Model mit Hilfe des vorangestellten Attributts [ObservableProperty] noch schlanker definieren kann. Dadurch muss man nur die lokale Variable definieren, der Codegenerator erzeugt den Rest in einer partiellen Klasse. 😎
Ich habe das mal kurz geprüft. Leider habe ich nur eine Fehlermeldung erhalten, dass die Klasse SimplePerson schon existiert. Ich habe sie dann als "partial" markiert. Und dann funktionierte dies. Vielen Dank. Das werde ich in einem Update zeigen, welches u.a. auch andere Denkfehler aufzeigen wird.
Top Video #Daumen hoch. Es war tatsächlich ein Aha Moment ;)
Danke dir 😁
Ich habe die Models und ViewModels gerne in separaten Projekten, da man somit einfach das UI Framework austauschen kann. Man kann dann einfach die bestehenden Projekte mit Models und ViewModels und der Geschäftslogik in das neue Projekt referenzieren und muss somit maximal NUR den UI Code und evtl. noch ein paar UI-frameworkspezifische Services neuschreiben.
Ja, wenn man den Code 1x schreibt, dann ist das gut, ein 2. Mal schreibt man ihn vielleicht noch, aber spätestens beim 3. Mal sollte man darüber nachdenken. Und da ist deine Vorgehensweise natürlich sehr charmant.
Kapitel manuell hinzugefügt. Keine Ahnung warum die nicht aus dem Video übernommen wurden.
Super Video. Ich habe allerdings noch nicht so ganz verstanden, wie es funktioniert, dass, wenn ich eine Klasse habe, die etwas berechnet, dass hier die Daten an das ViewModel übergeben werden und dann diese Daten dann an die Klasse weitergegeben werden. Kann das jemand beantworten?
Also wenn du in der UI-Oberfläche (View) etwas änderst, dann änderst du im ViewModel eine Eigenschaft, die im Prinzip auch nur eine Eigenschaft im Model ist. Da das View, das ViewModel und über das ViewModel auch die Klasse kennt, geht das einfach so. Das ViewModel hat ja eine Instanz des Models selbst und das View hat eine Instanz des ViewModels und somit änderst du durch Eingaben im View automatisch die Klasse im Model.
Siehe 24:18, da schreiben wir ja ins Binding "Eigenschaft (Property) im ViewModel" dann einen Punkt und dann "Eigenschaft (Property) in der Klasse".
Wenn du im Model etwas berechnest, dann ändert sich in der Klasse des Models eine Eigenschaft. Was das CommunityToolkitMVVM macht, es nimmt dir eine Menge Arbeit ab. Dazu wird eine Schnittstelle implementiert, die ein Event abfeuert, dass sich eine Eigenschaft geändert hat. Das ViewModel selbst hat das Event abonniert und empfängt dann die Änderung. Rückwärst hat das ViewModel eine direkte Verbindung, weil es selbst eine Instanz des Models also der Klasse hat. Deswegen benutzen wir das CommunityToolkit.MVVM, weil wir sonst richtig viel Arbeit mit der Implementierung von Schnittstellen wie INotifyPropertyChanged, INotifyPropertyChanging usw. haben.
Interessant wäre es zu wissen, wie man mit Dialogen umgeht.
Wenn du einen eigenen Dialog erstellt hast, dann kannst du das folgender Maßen erledigen. Gib dem Window einen Namen über x:Name, dann beim schließen Button nimmst du nicht nur das Command sondern auch den CommandParameter. Darin bindest du das Window, also ungefähr so {Binding Elementname=Name Fenster}. So ähnlich zumindest. Im ViewModel erstellst du ein Relaycommand mit dem Parameter Window. Darin kannst du dann das Fenster schließen. Eine andere Möglichkeit bieten DialogServices. Es gibt noch viele Fragen bei MVVM. Und es gibt auch Stimmen, die sagen, das ViewModel keine Berechtigung haben, man kann auch alles ins Codebehind des Views packen. Und auch hier hat das CommunityToolkit mit den Attributen [ObservableObject] und [ObservableRecipient] in der Window Codebehind Datei eine Möglichkeit.