INotifyPropertyChanged vs. DependencyProperty in ViewModel

Question

Bei der Implementierung des ViewModel in einer Model-View-ViewModel-Architektur WPF-Anwendung scheint es zwei große Möglichkeiten zu geben, wie man es databindable machen. Ich habe Implementierungen gesehen, die verwenden DependencyProperty für Eigenschaften, an die die Ansicht gebunden werden soll, und ich habe gesehen, dass das ViewModel die INotifyPropertyChanged stattdessen.

Meine Frage ist: Wann sollte ich das eine dem anderen vorziehen? Gibt es irgendwelche Leistungsunterschiede? Ist es wirklich eine gute Idee, die ViewModel-Abhängigkeiten an WPF zu übergeben? Was muss ich sonst noch bei der Entwurfsentscheidung berücksichtigen?

Answer 1

Kent hat einen interessanten Blog über dieses Thema geschrieben: Modelle ansehen: POCOs versus DependencyObjects .

Kurze Zusammenfassung:

1. DependencyObjects sind nicht als serialisierbar
2. Die DependencyObject-Klasse überschreibt und versiegelt die Equals()- und GetHashCode() Methoden
3. Ein DependencyObject hat Thread-Affinität - auf es kann nur zugegriffen werden auf dem Thread zugegriffen werden, auf dem es erstellt wurde

Ich bevorzuge den POCO-Ansatz. Eine Basisklasse für PresentationModel (auch bekannt als ViewModel), die die Schnittstelle INotifyPropertyChanged implementiert, finden Sie hier: http://compositeextensions.codeplex.com

Answer 2

Laut dem WPF-Leistungshandbuch führen DependencyObjects definitiv besser als POCOs, die INotifyPropertyChanged implementieren:

http://msdn.microsoft.com/en-us/library/bb613546.aspx

Answer 3

Die Wahl hängt ganz von Ihrer Geschäftslogik und der Abstraktionsebene der Benutzeroberfläche ab. Wenn Sie nicht wollen, eine gute Trennung dann DP wird für Sie arbeiten.

DependencyProperties werden hauptsächlich auf der Ebene der VisualElements angewendet, so dass es nicht sinnvoll ist, viele DPs für jede unserer Geschäftsanforderungen zu erstellen. Außerdem sind die Kosten für DP höher als für INotifyPropertyChanged. Wenn Sie eine WPF/Silverlight entwerfen, versuchen Sie, UI und ViewModel völlig getrennt zu entwerfen, so dass wir zu jedem Zeitpunkt das Layout und die UI-Steuerelemente ändern können (basierend auf Thema und Stile)

Siehe auch diesen Beitrag - https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel . Der Link enthält viele Verweise auf das Model-View-ViewModel-Muster, das für diese Diskussion sehr relevant ist.

Answer 4

Vom Standpunkt der Ausdruckskraft aus betrachtet, genieße ich die Verwendung von Abhängigkeitseigenschaften sehr und erschaudere bei dem Gedanken an INotifyPropertyChanged . Abgesehen von der string Eigenschaftsnamen und mögliche Speicherlecks aufgrund von Ereignisabonnements, INotifyPropertyChanged ist ein viel eindeutigerer Mechanismus.

Abhängigkeitseigenschaften implizieren "wenn dies, dann das" unter Verwendung leicht verständlicher statischer Metadaten. Es ist ein deklarativer Ansatz, der meine Stimme für Eleganz erhält.

Answer 5

Abhängigkeitseigenschaften sollen die Bindung (als Ziel) an UI-Elemente unterstützen und nicht als Quelle für die Datenbindung dienen; hier kommt INotifyProperty ins Spiel. Aus reiner Sicht sollten Sie DP nicht auf einem ViewModels verwenden.

"Um die Quelle einer Bindung zu sein, muss eine Eigenschaft keine Abhängigkeitseigenschaft sein; Sie können jede CLR-Eigenschaft als Quelle für eine Bindung verwenden. Allerdings, um das Ziel einer Bindung zu sein, muss die Eigenschaft eine Abhängigkeitseigenschaft sein. Damit eine einseitige oder zweiseitige Bindung wirksam ist, muss die Quelleigenschaft Änderungsbenachrichtigungen unterstützen, die an das Bindungssystem und somit an das Ziel weitergegeben werden. Für benutzerdefinierte CLR-Bindungsquellen bedeutet dies, dass die Eigenschaft INotifyPropertyChanged unterstützen muss. Sammlungen sollten INotifyCollectionChanged unterstützen."

Alle Abhängigkeitsobjekte können nicht serialisiert werden (Dies könnte die Verwendung von ViewModels und DTO (POCO) behindern.

Es gibt Unterschiede zwischen DP in Silverlight im Vergleich zu WPF.

http://msdn.microsoft.com/en-us/library/cc221408(v=VS.95).aspx

http://msdn.microsoft.com/en-us/library/cc903933(VS.95).aspx