Зависимость от DependencyObject и DependencyProperty

Question

Я создаю приложение Silverlight, и одно из моих предостережений в прошлый раз заключалось в том, что если вам нужно что-то сделать правильно в Silverlight/WPF, вам нужно смоделировать свои объекты как DependecyObject и использовать DependencyProperty(ies)

Я считаю эту модель довольно громоздкой, требующей статических полей и инициализаторов в половине классов, которые я использую, так стоит ли использовать старый добрый управляемый событиями шаблон (шаблон наблюдателя?) вместо DependencyObject?

Я стремлюсь свести к минимуму раздувание кода и шаблоны (я их ненавижу), и мне очень хотелось бы знать, есть ли у кого-нибудь с опытом работы в Silverlight/WPF какие-либо советы/методы, позволяющие свести к минимуму использование DependencyObject и DependencyProperty?

Это хорошая идея?

Answer 1

На самом деле, в Silverlight вы не можете наследовать DependencyObjects, поэтому вместо этого вам следует (и придется) реализовать INotifyPropertyChanged.

Реализация INotifyPropertyChanged имеет много преимуществ по сравнению с DependencyObjects (я буду сокращать этот DO, чтобы было проще) и использованием DependencyProperties (DP):

• Это более легкий
• Дает вам больше свободы в моделировании ваших объектов.
• Может быть легко сериализован
• Вы можете вызвать событие, когда захотите, что может быть полезно в определенных сценариях, например, когда вы хотите объединить несколько изменений только в одну операцию пользовательского интерфейса или когда вам нужно вызвать событие, даже если данные не изменились (чтобы принудительно перерисовать...)

С другой стороны, наследование DO в WPF имеет следующие преимущества:

• Легче реализовать, особенно для новичков.
• Вы получаете механизм обратного вызова (почти) бесплатно, позволяющий получать уведомления при изменении значения свойства.
• Вы получаете механизм принуждения, позволяющий определять правила для максимальной, минимальной и текущей стоимости имущества.

Есть и другие соображения, но это основные.

Я думаю, что общее мнение таково, что DP отлично подходят для элементов управления (и вы можете реализовать CustomControl с пользовательскими DP даже в Silverlight), но для объектов данных лучше реализовать INotifyPropertyChanged.

HTH, Лоран

Answer 2

Это действительно зависит от того, какие объекты вы имеете в виду.Если объект предназначен для размещения в дереве XAML, лучше всего использовать DependencyProperties (и, таким образом, наследовать DependencyObject - что делают все UIElements), чтобы реализовать все преимущества, которые предоставляют DependencyProperties (анимация, привязка, необязательное автоматическое дочернее наследование и т. д.).Я настоятельно рекомендую вам прочитать Обзор MSDN по DependencyProperties если вы еще этого не сделали.

Если объект является объектом данных (т.вы привязываете его значения к чему-то в дереве XAML), тогда нет необходимости наследовать от DependencyObject.Если свойства объекта доступны для чтения и записи, вы можете реализовать INotifyPropertyChanged, что позволит привязкам автоматически обновляться при изменении значения.

Answer 3

Я согласен с Ричардом, что это зависит от цели вашего класса, но, как примечание, кажется, что вы МОЖЕТЕ наследовать от DependencyObject непосредственно в выпуске Silverlight 2.0, без необходимости наследования от UIElement или UserControl.По крайней мере, я делаю это в своем приложении (SilverLight 2.0 RTW).

System.Windows.DependencyObject в MSDN

Это не типично для получения непосредственно из DependencyObject для большинства сценариев.Вместо этого вы можете получить производный элемент от определенного элемента управления, от одного из базовых классов элемента управления (ContentControl;Контроль;ItemsControl), из FrameworkElement или из неуправляющих классов, которые по-прежнему участвуют в пользовательском интерфейсе, например Panel или Grid.Наследование от DependencyObject может быть уместным, если вы определяете бизнес-объект или объект хранения данных, в котором вы хотите, чтобы свойства зависимостей были активными, или если вы создаете класс поддержки служб, который будет владеть прикрепленными свойствами.

ХТХ