Использование свойства зависимости в WPF
var test = '0test';
test = test.replace(/0(.*)/, '$1');
3 ответа
Преимущество в основном двоякое:
Во-первых, зависимость свойство создается только тогда, когда оно используется, это означает, что класс TextBox может быть очень эффективным, с небольшим объемом памяти, поскольку он имеет минимальное количество реальных свойств, занимающих место в куче. Это особенно важно в WPF, где все элементы управления представляют собой просто коллекции все более и более конкретных типов. Если бы каждый из этих внутренних типов объявлял десятки свойств для определения поведения и внешнего вида, тогда элемент управления высокого уровня, такой как кнопка, в конечном итоге имел бы размер класса с примерно сотней свойств.
Во-вторых, свойства зависимостей могут быть привязаны к объекту, отличному от типа, для которого они созданы. Это допускает случай, когда элемент управления может установить свойство Grid.Column, которое элемент управления Grid может читать и использовать для макета. Это означает, что у нас нет сотен классов декораторов, предоставляющих крошечные функциональные возможности, необходимые для других элементов управления. Это означает, что xmal гораздо более интуитивно понятен и удобочитаем.
Отредактировано, чтобы обратиться к примеру из вашего измененного вопроса:
Хотя ваше свойство проверки не получит особой выгоды от того, что оно является свойством зависимости (в основном по причинам во всех ответы до сих пор я действительно могу видеть только мой комментарий о следе памяти, поступающем в игру), и это, безусловно, не выгодно, как в случае свойства Text текстового поля, где вы можете захотеть его привязать, или измените его на основе какого-либо другого ввода, я бы все равно реализовал его как свойство зависимости. Мои доводы просты; ты не Я много выиграл, но это вам ничего не стоит - я никогда не жалел, что использовал базовое свойство в настраиваемом элементе управления, тогда как, когда я впервые начал их писать, я постоянно обновлял свои базовые свойства до зависимостей, потому что мне нужны были дополнительные функции .
Проще говоря, хотя свойство зависимости сложнее определить, это обычное свойство, я бы все равно использовал его как стандарт де-факто для элементов управления WPF, если только не было веской причины поступить иначе. Во многом так же, как свойство является стандартом для классов, хотя поле проще реализовать.
Это вам ничего не стоило - я никогда не жалел, что использовал базовое свойство в настраиваемом элементе управления, тогда как, когда я впервые начал их писать, я постоянно обновлял свои базовые свойства до зависимостей, потому что мне нужны были дополнительные функции.Проще говоря, в то время как Свойство зависимости сложнее определить, это обычное свойство, я бы все равно использовал его как стандарт де-факто для элементов управления WPF, если только не было веской причины поступить иначе. Во многом так же, как свойство является стандартом для классов, хотя поле проще реализовать.
Это вам ничего не стоило - я никогда не жалел, что использовал базовое свойство в настраиваемом элементе управления, тогда как, когда я впервые начал их писать, я постоянно обновлял свои базовые свойства до зависимостей, потому что мне нужны были дополнительные функции.Проще говоря, в то время как Свойство зависимости сложнее определить, это обычное свойство, я бы все равно использовал его как стандарт де-факто для элементов управления WPF, если только не было веской причины поступить иначе. Во многом так же, как свойство является стандартом для классов, хотя поле проще реализовать.
хотя поле проще реализовать. хотя поле проще реализовать.Свойства зависимости требуются, если вы хотите использовать привязку для заполнения значения свойства. Если бы это было обычное свойство, вы не смогли бы привязать свойство Text, например, к свойству вашего объекта модели представления.
Я бы сказал, что основные преимущества:
- Первоклассная поддержка привязки данных.
- Семантика чистого присоединенного свойства
- Значения свойств которые «зависят».
Эта последняя точка - ключ
Перед свойствами зависимости, имеющими значение, имеющее локальное значение, анимируемое значение, переопределяемое значение, стилизованное значение, шаблонное значение потребует объявления нескольких свойств / полей / словарных статей, а также сложное управление состоянием + приоритетом.
Свойства зависимостей предоставляют вам все эти функции из коробки, при этом объявляется только ОДНО свойство.
При этом в вашем случае вы можете не объявлять свои ValidationRules как DependencyProperty, если вам не нужно воспользуйтесь преимуществами этих функций.
Если вы это сделаете, вам потребуется другая обработка ваших коллекций (например, непустых коллекций). В этом конкретном примере я бы использовал Reflector и посмотрел, как .NET TextBox реализует свои проверочные коллекции, и посмотрел, можно ли повторно использовать или скопировать код.
Нет смысла изобретать колесо, если только вы не наверняка ваше колесо будет лучше. Мой личный опыт показывает, что в моих изобретенных заново колесах часто не хватает чего-то;).
Как уже отмечал Мартин Харрис, DependencyProperties может ограничить объем памяти, поместив значения свойств в словарь, однако это может (и я полагаю, было?) Сделано MSFT до появления DependencyProperties.
Мартин также упоминает прикрепленные свойства, но они также были доступны (по адресу по крайней мере в дизайнере) до появления DependencyProperties. Реализация присоединенного свойства с использованием DependencyProperties намного чище.