Dépendance de DependencyObject et de DependencyProperty

Question

Je construis une application Silverlight et l'une de mes mises en garde de la dernière fois était que si vous avez besoin de quelque chose de bien dans Silverlight/WPF, vous devez modéliser vos objets comme DependecyObject et utiliser DependencyProperty Je trouve ce modèle assez compliqué, nécessitant des champs statiques et des initialiseurs dans la moitié des classes que j'utilise, donc c'est une bonne idée d'utiliser le bon vieux modèle événementiel (pattern d'observateur?) en place de DependencyObject? Je vise à minimiser les ballonnements de code et les plaques de chaudière (je les déteste) et voudrais vraiment savoir si quelqu'un ayant de l'expérience dans Silverlight/WPF a des conseils/techniques pour garder l'utilisation de DependencyObject et DependencyProperty à un minimum?

Est-ce une bonne idée?

Answer 1

En réalité, dans Silverlight, vous ne pouvez pas hériter de DependencyObjects et vous devez donc (et devez) implémenter INotifyPropertyChanged à la place.

mise en œuvre INotifyPropertyChanged présente de nombreux avantages DependencyObjects (je vais abréger ce faire pour le rendre plus facile) et en utilisant DependencyProperties (DPs):

• Ceci est plus léger
• vous permet une plus grande liberté dans la modélisation de vos objets
• Peut être sérialisé facilement
• Vous pouvez augmenter l'événement quand vous le souhaitez, ce qui peut être utile dans certains scénarios, par exemple lorsque vous souhaitez regrouper plusieurs modifications dans une seule opération d'interface utilisateur ou lorsque vous avez besoin pour déclencher l'événement même si les données ne changent pas (pour forcer redessiner ...)

D'autre part, héritant DOs en WPF ont les avantages suivants:

• plus facile à mettre en œuvre en particulier pour les débutants.
• Vous obtenez un mécanisme de rappel (presque) gratuitement, vous permettant d'être informé lorsque la valeur de la propriété change
• Vous obtenez un mécanisme de coercition vous permettant de définir des règles pour la valeur max, min et actuelle de la propriété.

Il existe d'autres considérations, mais ce sont les principaux. Je pense que le consensus général est que les DP sont parfaits pour les contrôles (et que vous pouvez implémenter un CustomControl avec des DP personnalisés même dans Silverlight), mais pour les objets de données, vous devriez plutôt implémenter INotifyPropertyChanged.

HTH, Laurent

Answer 2

Cela dépend vraiment des objets auxquels vous faites référence. Si l'objet est destiné à s'asseoir dans l'arborescence XAML, il est préférable d'utiliser DependencyProperties (et ainsi hériter DependencyObject - que tous les UIElements font) pour permettre tous les avantages fournis par DependencyProperties (animable, binding, héritage automatique des enfants optionnel, etc.). Je vous recommande fortement de lire le MSDN overview on DependencyProperties si vous ne l'avez pas déjà fait.

Si l'objet est une entité de données (c'est-à-dire que vous liez ses valeurs à quelque chose dans l'arborescence XAML), il n'est pas nécessaire d'hériter de DependencyObject. Si les propriétés de l'objet sont en lecture-écriture, vous pouvez implémenter INotifyPropertyChanged, ce qui permettra aux liaisons de se mettre automatiquement à jour lorsque la valeur change.

Answer 3

Je suis d'accord avec Richard que cela dépend du but de votre classe, mais comme une note, il semble que vous pouvez hériter de DependencyObject directement dans Silverlight version 2.0, sans avoir à hériter de UIElement ou UserControl. Au moins, je le fais dans mon application (SilverLight 2.0 RTW).

System.Windows.DependencyObject on MSDN

Il est pas typique pour dériver directement de DependencyObject pour la plupart des scénarios. Au lieu de cela, vous pouvez dériver d'un contrôle spécifique, d'une des classes de base de contrôle (ContentControl; Control; ItemsControl), de FrameworkElement, ou de classes non-control qui participent toujours à l'interface utilisateur comme Panel ou Grid. Dériver de DependencyObject peut être approprié si vous définissez une entreprise ou un objet de stockage de données dans lequel vous souhaitez que les propriétés de dépendance soient actives ou si vous créez une classe de support de service qui possédera des propriétés jointes.

HTH