INotifyPropertyChanged vs. DependencyProperty in Ansichtsmodell
https://stackoverflow.com/questions/291518
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Wenn das Ansichtsmodell in einer Model-View-Viewmodel Architektur WPF-Anwendung Umsetzung scheint es zwei wichtige Entscheidungen zu sein, wie es databindable zu machen. Ich habe Implementierungen, die die Ansicht wird binden, gegen und ich habe das Ansichtsmodell Umsetzung DependencyProperty verwenden gesehen INotifyPropertyChanged Objekte statt gesehen.
Meine Frage ist, wann sollte ich einen über den anderen vorziehen? Gibt es Performance-Unterschiede? Ist es wirklich eine gute Idee, die Ansichtsmodell Abhängigkeiten zu WPF geben? Was muss ich beachten müssen, wenn die Design-Entscheidung machen?
Lösung
Kent schrieb einen interessanten Blog zu diesem Thema: Ansicht Modelle: POCOs im Vergleich DependencyObjects .
Kurze Zusammenfassung:
- DependencyObjects sind nicht markiert als serializable
- Die DependencyObject-Klasse überschreibt und dichtet das Equals () und GetHashCode () Methoden
- A DependencyObject hat Threadaffinität - es kann nur zugegriffen werden, auf das Gewinde auf dem sie war, erstellt
Ich ziehe den POCO-Ansatz. Eine Basisklasse für PresentationModel (auch bekannt als Ansichtsmodell), die INotifyPropertyChanged-Schnittstelle implementiert finden Sie hier: http://compositeextensions.codeplex.com
Andere Tipps
Nach dem WPF Performance Guide, DependencyObjects definitiv besser als POCOs die INotifyPropertyChanged implementieren:
Die Wahl ist völlig abhängig von Ihrer Business-Logik und UI-Abstraktionsebene. Wenn Sie nicht wollen, eine gute Trennung dann DP für Sie arbeiten.
DependencyProperties wird hauptsächlich anwendbar sein auf die VisualElements so nivellieren wird es nicht gut, wenn wir viele DPs für jeden unserer Geschäftsanforderungen erstellen. Auch gibt es eine höhere Kosten für DP als ein INotifyPropertyChanged. Wenn Sie einen WPF-Design / Silverlight try separate UI und Ansichtsmodell völlig so gestalten, dass an jedem Punkt der Zeit können wir das Layout und die UI-Steuerelemente (Basierend auf Thema und Styles) ändern
auch diesen Beitrag finden - https: // stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel . Der Link hat eine Menge Bezug auf Model-View-Viewmodel-Muster, das zu dieser Diskussion sehr relevant ist.
Aus Ausdruck Standpunkt mag ich gründlich Abhängigkeitseigenschaften mit und bei dem Gedanken an INotifyPropertyChanged erschaudern. Neben den string Eigenschaftsnamen und mögliche Speicherlecks aufgrund von Ereignis-Anmeldungs-, INotifyPropertyChanged ist ein viel expliziter Mechanismus.
Abhängigkeitseigenschaften bedeuten „wenn dies zu tun, dass“ statische Metadaten leicht verständlich werden. Es ist ein deklarativer Ansatz, meine Stimme für Eleganz wird.
INotifyPropertyChanged verwendet, wenn gibt Ihnen auch die Möglichkeit, mehr Logik in den Code Ihrer Getter und Setter Ihrer Eigenschaften hinzuzufügen.
DependencyProperty Beispiel:
public static DependencyProperty NameProperty = DependencyProperty.Register( "Name", typeof( String), typeof( Customer ) );
public String Name
{
set { SetValue( NameProperty, value ); }
get { return ( String ) GetValue( NameProperty ); }
}
In Ihrem Getter und Setter --- alles, was Sie tun können, ist einfach anrufen SetValue und GetValue bzw. b / c in anderen Teilen des Rahmens der Getter / Setter nicht aufgerufen wird, anstatt direkt ruft SetValue, GetValue, so dass Ihr Eigenschaft Logik würde nicht zuverlässig ausgeführt werden.
Mit INotifyPropertyChanged definiert ein Ereignis:
public event PropertyChangedEventHandler PropertyChanged;
Und dann haben Sie einfach eine beliebige Logik überall in Ihrem Code, dann rufen Sie:
// ...
// Something cool...
// ...
if( this.PropertyChanged != null )
{
PropertyChanged( this, new PropertyChangedEventArgs( "Name" ) );
}
// More cool stuff that will reliably happen...
Dies in einem Getter / Setter sein könnte, oder anderswo.
Abhängigkeitseigenschaften sind auf Träger bestimmt Bindung (als Ziel) auf UI-Elementen nicht als Quelle zu Datenbindung, das ist, wo INotifyProperty kommt. Aus reiner Sicht sollten Sie nicht DP verwenden auf einem Viewmodel.
"Um die Quelle einer Bindung zu sein, eine Eigenschaft, muss keine Abhängigkeitseigenschaft sein, man jede CLR-Eigenschaft als Bindungsquelle verwenden kann Um jedoch das Ziel eine Bindung zu sein, die Eigenschaft. eine Abhängigkeitseigenschaft sein muß. Für eine Einweg- oder Zweiweg-Bindung wirksam zu sein, muss die Quelleigenschaft-Änderungsbenachrichtigungen unterstützen, die an das Bindungssystem und damit das Ziel propagieren. Für benutzerdefinierte CLR Quellen Bindung bedeutet dies, dass die Eigenschaft muss Unterstützung INotifyPropertyChanged. Sammlungen sollten INotifyCollectionChanged unterstützen. "
Alle Abhängigkeits Objekte können nicht serialisiert werden (dies ist die Verwendung von Viewmodels und DTO (POCO) behindern könnte 's.
Es gibt Unterschiede zwischen DP innerhalb 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
Auch ich habe diese Entscheidung vor kurzem zu berücksichtigen.
Ich fand, dass die INotifyPropertyChanged Mechanismus besser für meine Bedürfnisse, weil es mir erlaubt, meine GUI zu einem bestehenden Geschäftslogik Rahmen zu kleben, ohne Zustand zu duplizieren. Der Rahmen war ich mit hatte einen eigenen Beobachter-Muster und es war einfach auf die nächste Ebene der Benachrichtigung zu übermitteln. Ich hatte einfach eine Klasse, die die Beobachter-Schnittstelle von meinem Business-Logik-Framework und dem INotifyPropertyChanged-Schnittstelle implementiert.
Mit DP können Sie das Backend definieren, dass der Staat selbst speichert. Ich würde .net-Cache eine Kopie jedes Element des Staates ich binde gehabt haben zu lassen. Dies schien wie ein unnötiger Overhead -. Mein Zustand ist groß und kompliziert
So, hier fand ich INotifyPropertyChanged besser für Eigenschaften von Geschäftslogik GUI aussetzt.
Dass gesagt wird, wo ich eine benutzerdefinierte GUI-Widget benötigt eine Eigenschaft und für Änderungen an dieser Eigenschaft zu belichten andere GUI-Widgets beeinflussen DP erwies sich die einfache Lösung.
So dort fand ich DP nützlich für die GUI GUI-Benachrichtigung.
Ist es wirklich eine gute Idee, die Ansichtsmodell Abhängigkeiten zu WPF geben?
.NET 4.0 wird System.Xaml.dll haben, so dass Sie nicht eine Abhängigkeit von einem beliebigen Rahmen nehmen müssen, um sie zu nutzen. Siehe Rob Relyea der Post über seine PDC-Sitzung.
Meine Meinung
XAML ist ein Sprachobjekte für die Beschreibung und WPF ist ein Framework, dessen beschriebenen Aufgaben sind UI-Elemente.
Ihre Beziehung ist ähnlich wie C #, eine Sprache zur Beschreibung von Logik und .NET, ein Rahmen, die bestimmten Arten von Logik implementiert.
XAML Zweck ist deklarative Objektgraphen. Die W * F-Technologien sind große Kandidaten für dieses Paradigma, aber XAML existiert unabhängig von ihnen.
XAML und das gesamte Abhängigkeitssystem wurden als separate Stapel für WF und WPF implementiert, wahrscheinlich die Erfahrung der verschiedenen Teams zu nutzen, ohne eine Abhängigkeit zu schaffen (kein Wortspiel beabsichtigt) zwischen ihnen.
Abhängigkeitseigenschaften sind der Leim von Custom Controls Schöpfung. Wenn Sie interessiert sind, sich mit der Intelli-Sense Ihre Eigenschaften im Eigenschaften-Fenster zu zeigen, in XAML Entwurfszeit Sie Abhängigkeitseigenschaften verwenden. INPC wird nie eine Eigenschaft im Eigenschaftsfenster zur Entwurfszeit an.
Es scheint, dass Abhängigkeitseigenschaften sollten in der Kontrollgruppe verwendet werden, die Sie wie Buttons erstellen. Um die Eigenschaften in XAML zu verwenden und alle WPF Funktionen verwenden, diese Eigenschaften müssen Abhängigkeitseigenschaften.
Allerdings Ihr Ansichtsmodell ist besser mit INotifyPropertyChanged. INotifyPropertyChanged Mit geben Ihnen die Möglichkeit, Getter / Setter-Logik haben, wenn Sie benötigen.
Ich empfehle Check-out Josh Smiths Version einer Basisklasse für ein Ansichtsmodell, das bereits implementiert INotifyPropertyChanged:
Ich denke, dies ist ein ausgezeichnetes Beispiel dafür, wie ein Ansichtsmodell zu tun.
Ich denke, DependencyProperty und INotifyPropertyChanged sind für zwei verschiedene Dinge verwendet in Bindung: die erste eine Eigenschaft zu ermöglichen, ein Ziel einer Bindung zu sein und die Eingabe von einer anderen Eigenschaft erhalten (Verwendung {Binding ...} die Eigenschaft festzulegen) der letzte, wenn Sie den Wert einer Eigenschaft wollen als Quelle einer Bindung (Name in der Binding Path Expression) verwendet werden. Deshalb ist die Wahl ist rein technischer Natur.
Ich ziehe einen direkteren Ansatz, den ich über gebloggt in Präsentationsmodell ohne INotifyPropertyChanged . Unter Verwendung einer Alternative zur Datenbindung können Sie binden direkt Eigenschaften CLR ohne Buchhaltung Code. Sie schreiben einfach nur alten .NET-Code in Ihrer Ansicht Modell, und es wird aktualisiert, wenn Ihr Datenmodell ändert.
Es gibt nur eine Sache, warum eine DependencyObject bevorzugen - Bindung wird besser funktionieren. Probieren Sie ein Beispiel mit einem ListBox und TextBox, bevölkert Liste mit Daten aus INotifyPropertyChanged Eigentum vs. DependencyProperty und bearbeiten aktuelles Element aus TextBox ...
Wenn Sie möchten, Eigenschaften zu anderen Steuerungen belichten Sie Abhängigkeitseigenschaften verwenden müssen ... Aber viel Glück, weil sie eine Weile dauern ... um herauszufinden,
