Laden...

MVVM - PropertyChanged von UserControl von anderem UserControl mitbekommen

Erstellt von Taucher vor 3 Jahren Letzter Beitrag vor 3 Jahren 672 Views
T
Taucher Themenstarter:in
307 Beiträge seit 2008
vor 3 Jahren
MVVM - PropertyChanged von UserControl von anderem UserControl mitbekommen

Hallo an alle,
ich habe mal generell die Frage, ob es denn in MVVM möglich ist, ob ein UserControl das PropertyChanged eines anderen UserControls mitbekommen kann, und das ohne Events?

Also um konkreter zu werden ein Beispiel: Ich habe eine UserControl, das ein TreeView enthält. Dieses UserControl befindet sich innerhalb eines anderen UserControls. Jetzt will ich mit dem anderen UserControl darauf reagieren, wenn sich das SelectedItem des TreeViews ändert.
Meine einzige Idee dazu jetzt wäre über Events.
Deshalb meine Frage, gibt es für das MVVM-Pattern da eine spezielle Lösung, das ich irgendwie von außen das PropertyChanged mitbekommen kann, oder müssen da wieder Events her?

D
30 Beiträge seit 2021
vor 3 Jahren

Hi,

ich würde jetzt aus dem Bauch heraus sagen, dass das mit InteractionTriggers funktionieren könnte.

Dabei kannst du auf die Events reagieren ohne im CodeBehind etwas machen zu müssen.

Folgender Namespace wäre entsprechend zu setzen:


      xmlns:i="http://schemas.microsoft.com/xaml/behaviors"

2.094 Beiträge seit 2012
vor 3 Jahren

Die DataTrigger können das auch, vermutlich sogar ein Stück besser.
Da ist egal, wo der Wert herkommt, es braucht nur ein Binding und einen Wert.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

T
Taucher Themenstarter:in
307 Beiträge seit 2008
vor 3 Jahren

Danke für die Infos.

Die DataTrigger können das auch, vermutlich sogar ein Stück besser.

Hast du da vielleicht ein Beispiel dafür?

16.864 Beiträge seit 2008
vor 3 Jahren

Siehe [Artikel] MVVM und DataBinding, da sind Trigger (auch DataTrigger) erklärt und auch entsprechend referenziert.

5.658 Beiträge seit 2006
vor 3 Jahren

Das UserControl ist die View (das "V" in MVVM), und das PropertyChanged-Ereignis gibt es nur im ViewModel (das "VM" in MVVM). Und die View kennt das ViewModel nicht, daher kennt das UserControl auch keine PropertyChanged-Ereignisse!

Das UserControl hat stattdessen DependencyPropertys (bzw. Ereignisse) als öffentliche API. Daran kannst du dann deine ViewModel-Eigenschaften binden, und natürlich auch DependencyPropertys von anderen Controls. Was innerhalb eines UserControls passiert, ist für den Rest der Anwendung völlig irrelevant.

Weeks of programming can save you hours of planning

2.094 Beiträge seit 2012
vor 3 Jahren

Und die View kennt das ViewModel nicht

Wie meinen? Müsste das nicht andersherum sein?
Das View bekommt eine Instanz des ViewModels als DataContext und muss daher auch den Typ kennen.
Die DataBindings werden ja auch von der View verwaltet, also kennt es auch die Properties.

Das ViewModel darf die View nicht kennen.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

5.658 Beiträge seit 2006
vor 3 Jahren

War ein bißchen mißverständlich ausgedrückt. Ein UserControl weiß nichts von MVVM oder vom ViewModel. Es kann mit oder ohne ViewModel eingesetzt werden. Deshalb gibt es im UserControl auch einen anderen Mechanismus für die Aktualisierung der Bindings (also DependencyProperties anstatt IPropertyChanged).

Und ein UserControl bekommt auch kein ViewModel als DataContext, sondern es werden Werte (keine ViewModels) an die DependencyProperties gebunden.

Meistens braucht man eh keine UserControls in WPF. Ein Anwendungsfall wäre, wenn es in unterschiedlichen Projekten wiederverwendet werden soll. Und dann muß es auch unabhängig vom verwendeten VM sein. Und bei ReactiveUI werden UserControls als IViewFor<T>eingesetzt, aber das ist hier nicht relevant. Und für alles andere ist ein Template ausreichend.

Weeks of programming can save you hours of planning

2.094 Beiträge seit 2012
vor 3 Jahren

Für sowas verwende ich meist das CustomControl, das sind dann die, die an mehreren Stellen mit mehreren ViewModels verwendet werden können.
Das CustomControl bekommt dann auch sauber definierte DependencyProperties und einen anständigen Style/Template, die mittels TemplateBinding (oder RelativeSource) auf die DPs zugreifen.
Oder ganz normale bereits bekannte Controls mit Styles/Templates, die auf AttachedDependencyProperties zugreifen.

Die UserControls sind bei mir meistens ausgelagerte Teile einer größeren View, sie sind also nicht unabhängig und dürfen dann auch einen DataContext zugewiesen bekommen.
Wirklich brauchen tut man die UserControls dafür nicht, ich nutze sie trotzdem, da komplexe Views in XAML leider schnell sehr unübersichtlich werden. Die UserControls dienen also hauptsächlich dazu, den Code lesbarer zu machen - oder z.B. in Listen, wenn es mehrfach genutzt wird und das gleiche ViewModel dahinter stehen kann/darf/soll.

Ist vielleicht etwas kleinkariert, aber mir ist der Unterschied wichtig ^^

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.