Использование свойств зависимости в WPF

Question

Мне трудно найти веские причины для свойства зависимости. Почему свойство «Text» System.Controls.TextBox является свойством зависимости, а не обычным свойством? Каким преимуществам он служит как свойство зависимости?

Одна из вещей, которую я пытаюсь выполнить, - добавить свойство ValidationRules в свой UserControl, которое будет содержать другие правила проверки. Как здесь:

<customControls:RequiredTextBox.ValidationRules>
                        <validators:NotNullOrEmptyValidationRule ErrorMessage="FirstName cannot be null or empty"/>
                    </customControls:RequiredTextBox.ValidationRules>

Проблема в том, что я не уверен, должно ли свойство ValidationRules быть DependencyProperty или просто обычным свойством.

Приведенный выше код выдает следующую ошибку:

{"Cannot add element to 'ValidationRules'; the property value is null.  Error at object 'LearningWPF.ValidationRules.NotNullOrEmptyValidationRule' in markup file 'LearningWPF;component/addcustomerwindow.xaml' Line 35 Position 66."}

Вот свойство ValidationRules:

 public static readonly DependencyProperty ValidationRulesProperty =
            DependencyProperty.Register("ValidationRules",
                                        typeof (Collection<ValidationRule>), typeof (RequiredTextBox),
                                        new FrameworkPropertyMetadata(null)); 

        public Collection<ValidationRule> ValidationRules
        {
            get { return (Collection<ValidationRule>)GetValue(ValidationRulesProperty); }
            set { SetValue(ValidationRulesProperty, value); }
        }

Answer 1

Преимущества в основном в два раза:

Во-первых, свойство зависимости создается только тогда, когда оно используется, это означает, что класс TextBox может быть очень эффективным, с небольшим объемом памяти, поскольку он имеет минимальное количество реальных свойств, занимающих пространство в куче. Это особенно важно в WPF, где все элементы управления являются просто коллекциями более и более конкретных типов. Если бы каждый из этих внутренних типов объявлял десятки свойств, определяющих поведение и выглядящих, тогда элемент управления высокого уровня, похожий на кнопку, в конечном итоге имел бы размер класса с чем-то на уровне сотен свойств.

Во-вторых, свойства зависимости могут быть связаны с объектом, отличным от типа, для которого они созданы. Это допускает случай, когда элемент управления может установить свойство Grid.Column, которое элемент управления Grid может читать и использовать для макета. Это означает, что у нас нет сотен классов декораторов, предоставляющих крошечные кусочки функциональности, требуемые другими элементами управления. Это означает, что xmal гораздо более интуитивно понятен и удобочитаем.

---

Отредактировано в соответствии с примером в вашем исправленном вопросе:

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

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

Answer 2

Основные преимущества, которые я бы сказал:

1. Первоклассная поддержка привязки данных.
2. Семантика чистого присоединенного свойства
3. Значения свойств, которые "зависят".

Последняя точка - ключ

Перед свойствами зависимостей, имеющими значение, имеющее локальное значение, анимируемое значение, переопределяемое значение, настраиваемое значение, изменяемое значение, потребуется объявление нескольких записей Properties / Fields / Dictionary, а также сложное состояние + приоритет управление.

Свойства зависимостей предоставляют вам все эти функции "из коробки", при этом объявляя только ОДНО свойство.

При этом в вашем случае вы можете не захотеть объявлять свои ValidationRules как DependencyProperty, если вам не нужно использовать эти функции.

Если вы это сделаете, вы захотите по-разному обрабатывать свои коллекции (например, непустые коллекции). В этом конкретном примере я хотел бы использовать Reflector и посмотреть, как .NET TextBox реализует их коллекции проверки, и посмотреть, можно ли повторно использовать или скопировать код.

Нет смысла заново изобретать колесо, если вы не уверены, ваше колесо будет лучше. Мой личный опыт показывает, что мои заново изобретенные колеса, как правило, пропускают вещи;)

Как уже указывал Мартин Харрис, DependencyProperties может ограничить объем памяти, выбрасывая значения свойств в словарь, однако это может (и я полагаю, что это было?) Сделано MSFT до появления DependencyProperties.

Мартин также упоминает Attached Properties, но они также были доступны (по крайней мере, в дизайнере) до появления DependencyProperties. Реализация Attached Property с использованием DependencyProperties намного чище.

Answer 3

Свойства зависимости необходимы, если вы хотите использовать привязку для заполнения значения свойства. Если бы это было просто обычное свойство, вы бы не смогли связать свойство Text со свойством вашего объекта View Model, например.