Прочитал про Dependency Property ( далее DP ) хотел бы проверить насколько я правильно понял


В движке WPF просто есть некий "Dictionary" который хранит объект, свойство и значение свойства для работы с DP.
То есть если запустить приложение и не назначать ни одного свойства — этот Dictionary будет пуст, создать 1000 000 объектов — Dictionary также будет пуст , как только у одного объекта установим значение отличное от по умолчанию, то в Dictionary поместиться одна запись.

Ну и соотвествено движок wpf отлавливает такие изменения и приводит в действие триггеры если они есть.

С другой стороны если свойство будет иметь уникальное значение — например ID объекта в базе, то если его сделать как DP и создать 1000000 объектов с уникальным ID, то данный "Dictionary" забьется и все начнет сильно тормозить, т.к. поиск будет занимать много времени.

Поэтому Dependency нужно создавать если :
— планируется использование в триггерах
— свойство мало изменяется ( например IsFocused — объект со значением true один на все приложение ) соотвествено поможет сэкономить память. Если будет много объектов с отличным по умолчанию значением, то память наоборот израсходуется намного больше.

Здравствуйте, Аноним, Вы писали:

А>В движке WPF просто есть некий "Dictionary" который хранит объект, свойство и значение свойства для работы с DP.
Да, только словарей много, и каждый dependency object хранит этот словарик внутри себя. Никакой валидации нет, т.е. любой dependency object может (но не должен) хранить значения для любых dependency property.

А>С другой стороны если свойство будет иметь уникальное значение — например ID объекта в базе, то если его сделать как DP и создать 1000000 объектов с уникальным ID, то данный "Dictionary" забьется и все начнет сильно тормозить, т.к. поиск будет занимать много времени.
Даже если бы словарь был один — нет. Средняя стоимость доступа всё равно O(1).

А>Поэтому Dependency нужно создавать если :
Вы _уже_ унаследованы от dependency object — пишете контрол (user control), или что-то, имеющее отношение к инфраструктуре WPF (за исключением команд и конвертеров).

Протаскивать классы/интерфейсы из System.Windows.* в остальные слои приложения не надо.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>В движке WPF просто есть некий "Dictionary" который хранит объект, свойство и значение свойства для работы с DP.
S>Да, только словарей много, и каждый dependency object хранит этот словарик внутри себя. Никакой валидации нет, т.е. любой dependency object может (но не должен) хранить значения для любых dependency property.

Вот тут по подробнее, пожалуйста
В DependencyObject от которого мы наследуемся — этот словарик объявлен статическим или он создается для каждого созданного объекта ?

Или там и то и другое — статичный глобальный словарь для регистрации DP и значений по умолчанию.
И локальный словарь на каждый объект — для его личных значений свойств.

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


А>>С другой стороны если свойство будет иметь уникальное значение — например ID объекта в базе, то если его сделать как DP и создать 1000000 объектов с уникальным ID, то данный "Dictionary" забьется и все начнет сильно тормозить, т.к. поиск будет занимать много времени.
S>Даже если бы словарь был один — нет. Средняя стоимость доступа всё равно O(1).

А>>Поэтому Dependency нужно создавать если :
S>Вы _уже_ унаследованы от dependency object — пишете контрол (user control), или что-то, имеющее отношение к инфраструктуре WPF (за исключением команд и конвертеров).

Да , но всегда же есть выбор, сделать свойство в контроле как обычное или как DP, вот я и предполагаю следующую формулу — если нужно его использовать в триггерах или оно редко меняется то однозначно DP, если же нет то уже можно думать насчет DP vs обычное.

Обычное свойство

public class MyControl : DependencyObject
{
   private int myPropValue;

   public int PropValue
   {
     get{ return myPropValue; }
     set{ myPropValue = value }
   }
}

или сделать его как DP :

public class MyControl : DependencyObject
{
   public object PropValue
   {
     get{ return (int)GetValue( "myProp" ); }
     set{ SetValue( "myProp", value ); }
   }
}

S>Протаскивать классы/интерфейсы из System.Windows.* в остальные слои приложения не надо.

А это что имеется ввиду ?

Здравствуйте, Аноним, Вы писали:

А>Вот тут по подробнее, пожалуйста
А>В DependencyObject от которого мы наследуемся — этот словарик объявлен статическим или он создается для каждого созданного объекта ?
Для каждого созданного:

public abstract class DependencyObject : IComponent, IDependencyObjectAccessor, IDisposable
{
  // ...
  private EffectiveValueEntry[] _effectiveValues; 

  // ...
}

Такие вопросы проще посмотреть рефлектором.

А>И еще момент хочу уточнить — записи в этот локальный словарь добавляются по мере изменения свойств, или же сразу загружаются весь список со значениями по умолчанию.
По мере изменения.

А>Да , но всегда же есть выбор, сделать свойство в контроле как обычное или как DP, вот я и предполагаю следующую формулу — если нужно его использовать в триггерах или оно редко меняется то однозначно DP, если же нет то уже можно думать насчет DP vs обычное.
Ещё есть биндинг и шаблоны контролов, поэтому проще не заморачиваться правилами. Класс унаследован от DepObject — используем dep property. Нет — свободен


S>>Протаскивать классы/интерфейсы из System.Windows.* в остальные слои приложения не надо.
А>А это что имеется ввиду ?
Сcылаться в логике приложения на типы из WPF — ICommand, Control, Window и т.д. и т.п.

аля

if (viewModel.DoSomethingCheckBox.IsChecked)
{
  DoSomething();
}

когда достаточно

if (doSomething)
{
  DoSomething();
}

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>Вот тут по подробнее, пожалуйста
А>>В DependencyObject от которого мы наследуемся — этот словарик объявлен статическим или он создается для каждого созданного объекта ?
S>Для каждого созданного:
S>

S>public abstract class DependencyObject : IComponent, IDependencyObjectAccessor, IDisposable
S>{
S>  // ...
S>  private EffectiveValueEntry[] _effectiveValues; 

S>  // ...
S>}
S>

S>Такие вопросы проще посмотреть рефлектором.

Спасибо ! Хорошая тулза.
Собственно у меня было представление именно об этом словарике, который используется в DependencyProperty.Register()

Объявлен он так

private static Hashtable PropertyFromName;

Единственное чтото пока не нашел прямых признаков его использование в DependencyObject.SetValue и DependencyObject.GetValue, не совсем тогда ясно зачем эта регистрация нужна, хотя обращение должно быть, хотя бы потому что валидаторы свойства через Register() вставляются

S>аля
S>

S>if (viewModel.DoSomethingCheckBox.IsChecked)
S>{
S>  DoSomething();
S>}
S>

S>когда достаточно
S>

S>if (doSomething)
S>{
S>  DoSomething();
S>}
S>

а doSomething откуда берется ?

Здравствуйте, Аноним, Вы писали:

А>Собственно у меня было представление именно об этом словарике, который используется в DependencyProperty.Register()
А>Объявлен он так
Не, PropertyFromName — это static-словарик для самих свойств, нужен для получения свойств по паре {тип, имя}.
Узнать можно так: в рефлекторе — правой кнопкой по полю, Analyze, Used By.

А _значения свойств_ хранятся в _effectiveValues в каждом DependencyObject.

А>а doSomething откуда берется ?
У меня, как правило, из параметров.