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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

НТН, Laurent

Answer 2

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

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

Answer 3

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

System.Windows.DependencyObject на MSDN

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

НТН