DependencyObject.SetValue против приведения и установки свойства
У меня есть свойство, измененное обратным вызовом, и в нем мне нужно выполнить некоторую проверку.
Я собираюсь взять новое значение и проверить его по ряду других критериев свойств, таких как минимальное и максимальное значения.
Для этого я планирую либо взять объект зависимости из измененного события и использовать
DependencyObject.SetValue(TargetProperty,NewValue);
или приведите его к переменной и используйте свойства напрямую
ObjectType myObjectType = (ObjectType)DependencyObject;
myObjectType.Target=NewValue;
Мой вопрос заключается в том, каковы причины использования одного метода над другим. Будет ли приведение больше потратить ресурсы, чем, скажем, много поисков SetValue/GetValue и т. Д.? Я буду ссылаться на свойства до 10 раз в методах.
Большое спасибо.
1 ответ
Стандартная реализация свойства зависимости в DependencyObject
это позвонить SetValue()
, Кроме того, литье очень дешево, особенно в этом контексте. Так что между этими двумя подходами нет никакой практической разницы.
Для меня все будет зависеть от того, на какой части операции вы хотите сосредоточиться. Если вы хотите, чтобы ваша реализация была тесно связана с тем фактом, что объект на самом деле DependencyObject
Я не вижу много причин, чтобы не звонить SetValue()
непосредственно. Вот что делает WPF.
С другой стороны, если вы хотите, чтобы код был более похож на C# и следовал нормальным идиомам доступа к свойству, приведение к правильному типу и последующая установка свойства будут более удобочитаемыми и поддерживаемыми. Да, он добавляет дополнительные операции приведения и последующего вызова метода установки свойств. Но это незначительные расходы, практически неизмеримые. И в ответ вы получаете код, который не предполагает какой-либо конкретной реализации свойства.