Laden...

PropertyChange Event in eine andere Klasse weiterleiten

Erstellt von _Cashisclay vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.477 Views
_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren
PropertyChange Event in eine andere Klasse weiterleiten

Hallo zusammen,

ich hab ein ViewModelA worin sich ein weiteres ViewModelB befindet. Gibt es irgendeinen bekannten Weg wie ich quasi das PropertyChange Event von ViewModelB in ViewModelA weiterleite um dort mitzubekommen der Wert hat sich ebenfalls geändert um das ggf. im IDataErrorInfo Interface abzufangen?

Oder macht man so etwas generell nicht?

Grüße

16.807 Beiträge seit 2008
vor 4 Jahren

Bitte immer erklären, was Du im Gesamten vor hast; ansonsten kann man nicht erkennen, ob es sich hier um ein Designfehler handelt oder nicht.

_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren

Eigentlich hab ich dazu schon alles geklärt.

Ich hab ViewModelA mit einem Model wo sich Daten drin befinden.
Ich habe ViewModelB wo sich ebenfalls das gleiche Model wiederfindet.

In ViewModelB zum Beispiel wird der Wert mit einem Datumsfeld verknüpft, wenn dieser sich ändert, beeinflusst das eine Datenvalidierung (IDataErrorInfo) in ViewModelA, deswegen würde ich gerne irgendwie das PropertyChange Event aus ViewModelB auch nach ViewModelA weiterleiten.

Daher meine Frage.

Grüße

709 Beiträge seit 2008
vor 4 Jahren

Kennt ViewModelA ein Objekt von ViewModelB?

_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren

A kennt alles von B aber B nichts von A.

301 Beiträge seit 2009
vor 4 Jahren

Warum implementiert ViewModelB nicht IDataErrorInfo?

_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren

Weil ViewModelA Felder hat die eine Datenvalidierung besitzen die abhängig sind von Werten aus ViewModelB.

709 Beiträge seit 2008
vor 4 Jahren

Dann könnte ViewModelA doch im einfachsten Fall das PropertyChanged-Event von ViewModelB abonnieren und sich dadurch informieren lassen.

301 Beiträge seit 2009
vor 4 Jahren

Ich habe mit solchen impliziten Abhängigkeiten eher schlechte Erfahrungen gemacht und kann daher nur davon abraten. Was ich meine?

-> ViewModelA hat ein Property welches sich aus 2 oder mehr Properties zusammensetzt die woanders liegen.

Ich würde empfehlen: Schreib konkrete Logik die dein zusammengesetztes Property wirklich ändert wenn sich eine der Abhängigkeiten ändert. Dadurch musst du keine bestimmte Logik mehr nachziehen wenn es um Validierung o.ä. geht, denn dein PropertyChanged wird ja wirklich geworfen weil es sich geändert hat. Das hat auch den Vorteil der Nachvollziehbarkeit im Code.

Zu deiner eigentlichen Ausgangsfrage:

Ich würde das PropertyChanged Event von ViewModelB fangen und in der Behandlung dein Property welches scheinbar eine Abhängigkeit hat neu Berechnen und Zuweisen. Das ganze kannst du dann auch easy durch einen Unittest abdecken.

Das wichtigste aber ist, du baust eine explizite Abhängigkeit die man leicht nachlesen kann. Ich persönlich halte nichts davon wenn ein Property mehrere PropertyChanged Ereignisse für andere Properties wirft nur weil sich diese scheinbar an etwas bedienen.

_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren

Dann könnte ViewModelA doch im einfachsten Fall das PropertyChanged-Event von ViewModelB abonnieren und sich dadurch informieren lassen.

Ja, würde ich normalerweise auch so machen, aber ViewModelB erbt von einer Klasse die sich darum kümmert, da komm ich dann doch nicht mehr so einfach an das Event ran oder?

_
_Cashisclay Themenstarter:in
277 Beiträge seit 2014
vor 4 Jahren

Ich würde empfehlen: Schreib konkrete Logik die dein zusammengesetztes Property wirklich ändert wenn sich eine der Abhängigkeiten ändert. Dadurch musst du keine bestimmte Logik mehr nachziehen wenn es um Validierung o.ä. geht, denn dein PropertyChanged wird ja wirklich geworfen weil es sich geändert hat. Das hat auch den Vorteil der Nachvollziehbarkeit im Code.

Hast du eventuell ein Beispiel für mich? Offensichtlich weiß ich ja aktuell nicht wie man es besser machen könnte, würde aber gerne eine ordentliche Lösung forcieren.

709 Beiträge seit 2008
vor 4 Jahren

Solange irgendwo in der Kette INotifyPropertyChanged implementiert wird, ist das PropertyChanged-Event public.