einfache DependencyProperty vs. normale Property mit browsable
Kann mir jemand den Unterschied zwischen einer DependencyProperty die ich nur mit Register() anlege und einer "normalen" Property mit [Browsable(true)]" erklären?
Das eine hat mit dem anderen doch gar nichts zu tun. Wie kommst du zu dieser Frage?
Das Browsable Attribute ist doch nur da um dem Designer sagen zu können, dass er das Property nicht anzeigen soll. Funktional ändert das Attribut gar nichts am Property. Es ist weiterhin nen klassisches .Net Property mit Get und Set Methode.
Die mit WPF eingeführten DependencyProperties sind ja grundsätzlich anders. Diese werden zentral verwaltet, bieten Change Notification usw..
Im Gegensatz zu den klassischen Properties repräsentieren DependencyProperties auch keinen konkreten Wert, sondern einen, durch verschiedene Abhängigkeiten (d.h. Dependency...) erzeugten, Wert.
Baka wa shinanakya naoranai.
Mein XING Profil.
Ok. macht es z.B: für eine Property "IsReadOnly" auf einem UserControl Sinn, diese als DP zu implementieren?
Edit: Das Thema sollte vielleicht lauten: "wann brauche ich eine DP und wann reicht eine normale Property?"
Eine DP für RegisterAttached() ist klar.
Hi,
ein DependencyProperty bietet viele zusätzliche Features im Vergleich zu normalen Properties
A dependency property provides functionality that extends the functionality of a property as opposed to a property that is backed by a field. Often, each such functionality represents or supports a specific feature of the overall WPF set of features:
Resources Data binding Styles Animations Metadata overrides Property value inheritance WPF Designer integration
Gruss
Michael
Ok. macht es z.B: für eine Property "IsReadOnly" auf einem UserControl Sinn, diese als DP zu implementieren?
Kommt drauf an 😃
Prinzipiell würde ich alle Properties die in einer WPF GUI verwendet werden, wie z.b. die Eigenschaften von Controls als DependencyProperties realisieren. Gerade um alle Vorzüge wie DataBinding, Animationen, Value Coercion, Change Notification usw. auskosten zu können. Klar gibts auch das Interface INotifyPropertyChanged welches man implementieren kann um zumindest den letztgenannten Punkt auch mit normalen Properties hinzubekommen, aber wieso sollte man? Mit DependencyProperties bekommt man das alles schon eingebaut.
Zumal DependencyProperties viel effektiver sind als normale Properties. Nur die DependencyProperties die man setzt, verbrauchen auch Speicherplatz, alle anderen nicht. Das ist mit den klassischen Properties anders, die immer( wenn der Propertywert nicht grad dynamisch berechnet ist) ein Feld dahinter haben. Und wenn man sich überlegt das einzelne Controls wie nen WPF Button alleine schon über hundert Properties haben und ne komplexe WPF GUI aus zig hundert gleichzeitig angezeigten Controls besteht, dann sieht man das DependencyProperties da massig Einsparungen bringen können.
Aber, DependencyProperties sind schön und gut, aber halt ein WPF Feature. Man sollte die nicht in Klassenbibliotheken verwenden die auch z.b. in Windows Forms benutzt werden. Das bringt nur unnötige Abhägigkeiten rein die nicht sein sollten. Da ist es besser auf klassische Properties zu setzten und ggf. Interfaces wie z.b. INotifyPropertyChanged zu verwenden.
Baka wa shinanakya naoranai.
Mein XING Profil.
Also Binding wär schon mal ein relevanter Grund.
Ich frag nämlich, weil ich sehr häufig seh, dass eine DP erstellt, dann Probleme mit dem nicht aufgerufenen Setter entstehen (dürfte bekannt sein) und in der Property eigentlich gar nix großartig gemacht wird, was irgendwie einer DP bedürfte.
z.B eine Property "Caption" auf einem UserControl die irgendwo in einem Label in dem Control einen Wert setzt. Oder "IsReadOnly" das nur auf true/false (ohne Binding) gesetzt wird und dann irgendwie noch 3 andere Sachen macht.
Für solche Sachen sind DPs doch ziemlich unnötig oder?
@talla:
Wenn ich z.B. IsReadOnly brauche (ohne DataBinding) und dazu einen Event der besagt ob das verändert wurde oder nicht, würdest du eine DP bauen oder nicht?
was meinst du mit "effektiver"? In welcher Hinsicht sind sie effektiver? Sie bieten mehr an klar. Wie bei "IsReadOnly": Was wäre in so einem Fall schneller bzw. performanter?
DependencyProperties sind ja statisch, aber wie wird der Wert in den Properties gespeichert??
Angenommen ich habe eine Klasse Mensch
mit den Eigenschaften
public static readonly DependencyProperty NameProperty = DependencyProperty.Register("Name", typeof(string), typeof(CusContainerBase));
public string Name
{
get { return (string)GetValue(NameProperty); }
set { SetValue(NameProperty, value); }
}
private string vorname;
public string Vorname
{
get{return vorname;}
set{vorname= value;}
}
Wenn ich jetzt 5 Instanzen von der Klasse anlege und in jeder Instanz unterschiedliche Werte angebe...
in dem normalen Property wird der jeweilige Wert in dem feld "vorname" gespeichert, aber wie siehts mit der NameProperty aus ? Die ist statisch, könnte doch eigendlich nur einmal existieren und nur EINEN Wert beinhalten ? Oder wie sieht das aus
Statisch ist eigentlich nur die "Definition" der Property. Soweit ich weiß speichert die WPF die Werte dann irgendwie/irgendwo in einem internen System/Speicher.
Hallo,
bin grad am überlegen ob ich über DependencyProperties nicht mal einen Artikel schreiben sollte 😉 Es scheint doch einige Missverständnisse zu geben wie DependencyProperties funktionieren.
@tkrasinger
Typischerweise verwendet man ja in WPF XAML um die GUI zu beschreiben, und da brauchst du DataBinding an jeder Ecke. Deine Variante mit normales Property + Event ist ja genau das Interface INotifyPropertyChanged, welches auch von allen WPF Mechanismen, als eine Möglichkeit der Change Notification verwendet wird. Trotzdem würde ich, wenns als Property eines WPF Controls verwendet wird, als Dependency Property deklarieren. Einfach um auch konsistent zu sein mit dem Rest von WPF. Zu den Effektiv schreib ich gleich was.
@Gepro
DependencyProperties an sind alles, nur nicht statisch 😃 Die Deklaration aber schon.
Bei der Deklaration sagst du dem DependencyProperty System mit Register das du gern ein Property hättest von Typ ... und das gehört zum Control ... usw. Dann bekommst du nen DependencyProperty Objekt zurück welches ja in der Variablen NameProperty gespeichert wird. Diese Variable verwendest du jetzt um auf das Property zugreifen zu können. Die Werte, werden dort aber nicht gespeichert!
Man kann sich das DependencyProperty System wie ne Art HashTable vorstellen. Mit der Register Methode sagst du welches Control gerne was für ein Property hätte und was du zurück bekommst (im obigen Fall das NameProperty) ist praktisch der Schlüssel mit dem du in der Tabelle dann auf den Wert zugreifen kannst. Das unterscheidet die DPs fundamental von den normalen Properties. Die DPs werden zentral verwaltet. Da natürlich auch das aktuelle Objekt mit zum Schlüssel zählt ist es natürlich möglich für jedes Objekt nen anderen Wert für das DependencyProperty zu setzen.
Das macht die DependencyProperties auch so effektiv. Nur wenn ich wirklich Werte in dieser Tabelle setzte, werden die gespeichert. Bei einem einzelnen Property ist es natürlich egal (deshalb lässt sich bei nem einzelnen Property wie IsReadOnly das auch so schwer beantworten ohne den Rest zu kennen), aber da in ner komplexen WPF GUI zig hunderte DependencyProperties gibt, fällts schon auf. Effektiv von allem im Sinne von Speicherplatz und schneller Zugriff. Was noch dadurch erst möglich wird ist, das sich Klassen Properties teilen: TextBlock und Control sind zwei WPF Klassen die unterschiedliche Klassenherachien entspringen. TextElement registriert für sich das Property FontFamilyProperty. TextBlock und Control fügen sich jetzt als zusätzliche Owner hinzu. Nun haben TextElement, TextBlock und Control das selbe Property. Nicht das gleiche, sondern wirklich haargenau das selbe. Nur dadurch funktionieren die Styles überhaupt so gut in WPF, da man dadurch auch Klassen die an sich nicht viel miteinander zu tun haben, Gemeinsamkeiten geben kann die dann durch die Styles beeinflusst werden können.
Baka wa shinanakya naoranai.
Mein XING Profil.
bin grad am überlegen ob ich über DependencyProperties nicht mal einen Artikel schreiben sollte 😉 Es scheint doch einige Missverständnisse zu geben wie DependencyProperties funktionieren.
Ein vernünftiger Artikel über:
"Was sind DPs? Wann brauche ich DPS, wann nicht? Wie lege ich diese an (snippet!)? Wie funktionieren sie und welche "Arten" gibt es (Attached, etc.)?
wär sicherlich sehr hilfreich. Für meinen Teil blick ich (denke ich) soweit durch, für mich war eben nur die Frage ob ich für ganz einfache Sachen eine DP brauche, weil es mir vorkommt, dass in der WPF nun grundsätzlich für alle Eigenschaften eines Controls eine DP angelegt wird.
... weil es mir vorkommt, dass in der WPF nun grundsätzlich für alle Eigenschaften eines Controls eine DP angelegt wird.
Ja, es ist auch sinnvoll da die Controls dafür gemacht werden, um in XAML mit DataBinding, Styles, Animation usw. verwendet zu werden. Und dafür braucht man zwingend DPs. Und da kann man auch nicht sagen, dieses Property mach ich jetzt nicht als DP da es mir zu "einfach" ist und man es bestimmt nie als DP braucht. Potentiell wird jedes Property eines Controls von irgend einem Anwender mal verwendet mit den ganzen WPF Mechanismen und der wird den Controlentwickler jagen wenn das dann nicht tut, weils kein DependencyProperty ist 😉
Baka wa shinanakya naoranai.
Mein XING Profil.