Dépendance de DependencyObject et DependencyProperty

Question

Je construis une application Silverlight et une de mes mises en garde de la dernière fois est que si vous avez besoin de tout faire correctement dans Silverlight / WPF, vous devez modéliser vos objets en tant que DependecyObject et utiliser DependencyProperty (s)

Je trouve ce modèle assez encombrant, nécessitant des champs statiques et des initialiseurs dans la moitié des classes que j'utilise. Il est donc judicieux d'utiliser le bon vieux modèle (modèle d'observateur?) à la place de DependencyObject? <

Mon objectif est de minimiser les erreurs de code et les plaques de chaudière (je les déteste) et j'aimerais vraiment savoir si quelqu'un ayant de l'expérience dans Silverlight / WPF a des astuces / techniques pour réduire au minimum l'utilisation de DependencyObject et de DependencyProperty? / p>

Est-ce une bonne idée?

Answer 1

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

Implémenter INotifyPropertyChanged présente de nombreux avantages par rapport à DependencyObjects (je vais abréger cette opération pour le rendre plus facile) et à l’utilisation de DependencyProperties (DP):

• C'est plus léger
• vous permet plus de liberté dans la modélisation de vos objets
• Peut être sérialisé facilement
• Vous pouvez déclencher 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 devez déclencher l'événement même si les données ne l'ont pas été. changer (pour forcer redessiner ...)

D'un autre côté, les tâches héritées dans WPF présentent les avantages suivants:

• Plus facile à mettre en œuvre, spécialement pour les débutants.
• Vous bénéficiez (presque) gratuitement d'un mécanisme de rappel vous permettant d'être averti lorsque la valeur de la propriété change
• Vous obtenez un mécanisme de contrainte avec qui vous permet de définir des règles pour les valeurs maximales, minimales et actuelles de la propriété.

Il y a d'autres considérations, mais ce sont les principales.

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é à figurer dans l'arborescence XAML, il est préférable d'utiliser DependencyProperties (et donc d'hériter DependencyObject - comme le font tous les droits UIE) afin de permettre à tous les avantages fournis par DependencyProperties (animabilité, liaison, héritage enfant facultatif automatique, etc.). Je vous recommande vivement de lire la Présentation de MSDN sur DependencyProperties si vous n'avez pas encore t déjà.

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 souhaiterez peut-être implémenter INotifyPropertyChanged , qui permettra aux liaisons de se mettre à jour automatiquement lorsque la valeur change.

Answer 3

Je suis d'accord avec Richard sur le fait que cela dépend de l'objectif de votre classe, mais il convient de noter que vous POUVEZ hériter de DependencyObject directement dans Silverlight 2.0 Release, sans avoir à hériter de UIElement ou de UserControl. Au moins, je le fais dans mon application (SilverLight 2.0 RTW).

System.Windows.DependencyObject sur MSDN

  

Il est pas typique de 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, de l'une des classes de base de contrôle (ContentControl; Control; ItemsControl), de FrameworkElement ou de classes non contrôlées qui participent toujours à une interface utilisateur telle que Panel ou Grid. Dériver à partir de DependencyObject peut être approprié si vous définissez un objet de stockage d’entreprise ou de stockage de données sur 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 attachées.

HTH