Когда использовать свойство зависимости WPF по сравнению с INotifyPropertyChanged - PullRequest
35 голосов
/ 23 августа 2010

Есть ли у людей какие-либо рекомендации относительно того, когда простого свойства .NET, которое вызывает INotifyPropertyChanged.PropertyChanged, достаточно в модели представления?Тогда когда вы хотите перейти к полноценному свойству зависимости?Или ПЛ предназначены в основном для представлений?

Ответы [ 5 ]

52 голосов
/ 24 августа 2010

Есть несколько подходов:

1. Свойство зависимости

Когда вы используете свойство зависимостей, оно имеет смысл в элементах-классах, которые имеют визуальный вид (UIElement s).

Плюсы:

  • WPF сделает всю логику за вас
  • Некоторые механизмы, например анимация, используют только свойство зависимостей
  • Подходит для стиля ViewModel

Минусы:

  • Вам нужно получить форму DependencyObject
  • Немного неудобно для простых вещей

Пример:

public static class StoryBoardHelper
{
    public static DependencyObject GetTarget(Timeline timeline)
    {
        if (timeline == null)
            throw new ArgumentNullException("timeline");

        return timeline.GetValue(TargetProperty) as DependencyObject;
    }

    public static void SetTarget(Timeline timeline, DependencyObject value)
    {
        if (timeline == null)
            throw new ArgumentNullException("timeline");

        timeline.SetValue(TargetProperty, value);
    }

    public static readonly DependencyProperty TargetProperty =
            DependencyProperty.RegisterAttached(
                    "Target",
                    typeof(DependencyObject),
                    typeof(Timeline),
                    new PropertyMetadata(null, OnTargetPropertyChanged));

    private static void OnTargetPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        Storyboard.SetTarget(d as Timeline, e.NewValue as DependencyObject);
    }
}

2. System.ComponentModel.INotifyPropertyChanged

Обычно при создании объекта данных вы используете этот подход. Это простое и аккуратное решение для подобных вещей.

Плюсы и минусы - дополняют 1. Вам нужно реализовать только одно событие (PropertyChanged).

Образец:

public class Student : INotifyPropertyChanged 
{ 
   public event PropertyChangedEventHandler PropertyChanged; 
   public void OnPropertyChanged(PropertyChangedEventArgs e) 
   { 
       if (PropertyChanged != null) 
          PropertyChanged(this, e); 
   } 
}

private string name; 
public string Name; 
{ 
    get { return name; } 
    set { 
           name = value; 
           OnPropertyChanged(new PropertyChangedEventArgs("Name")); 
        } 
} 

3.PropertyName Изменено

Повышение события для каждого свойства с указанным именем (например, NameChanged). Событие должно иметь это имя, и вы должны его обработать / поднять. Подобный подход как 2.

4. Получи переплет

Используя FrameworkElement.GetBindingExpression(), вы можете получить объект BindingExpression и позвоните BindingExpression.UpdateTarget(), чтобы обновить.

Первое и второе наиболее вероятны в зависимости от вашей цели.

В целом, это Visual против данных.

14 голосов
/ 24 августа 2010

Насколько я знаю, DependencyProperty требуется только тогда, когда вам нужно

  1. PropertyValue наследство
  2. вам нужно разрешить установку свойства в настройках стиля
  3. Использовать анимацию для свойства

и т.д..

Эти функции не будут доступны с обычными свойствами.

4 голосов
/ 20 июля 2012

DependencyProperty требуется, если вы хотите разрешить привязку к свойству. Обычно это для пользовательских UIElement, которые вы создаете. Вы хотите, чтобы люди могли связывать данные с вашими UIElement s.

<local:MyUIElement MyProperty={Binding Path=SomethingToBindTo} />

Для этого необходимо, чтобы MyProperty был свойством зависимости

1 голос
/ 21 января 2016

Как уже было сказано в других ответах о том, когда создавать свойство зависимостей.т.е.

  1. PropertyValue наследование
  2. вам необходимо использовать привязку к свойству
  3. Использовать анимацию для свойства

Еще одна перспектива / вопрос по этому вопросу: «В приложении WPF имеет смысл создавать свойства зависимостей в элементе управления, поскольку они могут измениться во время взаимодействия с пользователем, например, Высота, ширина, текст, содержимое, фон и т. Д. , ноа как насчет других классов, таких как классы поведения (не UI-классы). Должны ли свойства в этих классах быть свойством зависимости? "

Я не скажу за абсолютность или акцент на некотором наборе правилздесь, но вы должны создать свои свойства как DP.С точки зрения дизайна, если свойство DP, в WPF всегда используется форма по умолчанию / bind.ie

  1. Поскольку DP гораздо быстрее / естественнее в отражении изменений, чем в обычномСвойство CLR.
  2. DP имеет механизм проверки для подтверждения присвоенного значения и структуру по умолчанию для возврата значения.
  3. DP имеет обратный вызов значения Coerce для управления пределами свойства.
  4. У DP есть метаданные, связанные с ним, в отличие от свойства CLR.

С точки зрения практики, я видел, как люди делали много ошибок во вложенных привязках, а затем вызывали изменения такого рода ошибок.не происходит с ДП из-за его дизайна и совместимости самого изменения.Таким образом, с небольшим дополнительным синтаксисом вы добавляете гибкость / производительность / легкость вашему приложению.Так что делайте это везде, где это возможно.

Все еще не могу сказать наверняка для классов ViewModel / других вспомогательных классов.обновит ответ, если найдут убедительные причины в будущем.

Просто пост стоит прочитать на эту тему

1 голос
/ 14 января 2013

Основная проблема, которую я вижу с INotifyPropertyChanged, заключается в том, что если ваша viewmodel является сложной, содержащей много вложенных типов, то, по-видимому, вы должны всплыть событие PropertyChanged в иерархии.

...