Нормы привязки WPF нормализованы под капотом?

Question

Мне просто интересно, имеет ли это какое-то значение, повторяю ли я подпуть к некоторому свойству в каждой привязке или я связываю DataContext и указываю только относительные пути в привязках.

Примеры:

Абсолютные пути:

<UserControl x:Name="uc"/>
  <StackPanel>
    <TextBox Text="{Binding ViewModel.Prop1, ElementName=uc}" />
    <TextBox Text="{Binding ViewModel.Prop2, ElementName=uc}" />
  </StackPanel>
</UserControl/>

Относительные пути:

<UserControl x:Name="uc"/>
  <StackPanel DataContext="{Binding ViewModel, ElementName=uc}">
    <TextBox Text="{Binding Prop1}" />
    <TextBox Text="{Binding Prop2}" />
  </StackPanel>
</UserControl/>

Я знаю, что оба они связывают одни и те же свойства, но мне интересно, что на самом деле происходит за кулисами,потому что, возможно, это может повлиять на производительность в ситуациях, когда существует более двух привязок.Приведет ли вариант с абсолютными путями к большему «трафику событий», поскольку каждая из привязок текста соблюдает свойство ViewModel и его конкретное свойство?Или это будет точно так же?Я мог бы вообразить некоторый BindingManager, разрешающий все пути привязки, s.th.оба варианта заканчиваются одним и тем же IL.

Если структура иерархии привязки действительно оказывает влияние: есть ли положительный эффект (помимо предпочтений стиля кода) использования «более медленного» подхода с полными путями вкаждая привязка?

Answer 1

Как только объект привязки создан, не имеет значения, насколько сложной была разметка, которая его создала; объект содержит ссылку на свойство источника, и то, как эта ссылка была найдена, больше не имеет значения. Таким образом, единственное влияние на производительность при выполнении этого одностороннего действия будет при создании экземпляра самой привязки.

Мало того, что вы не будете повторять, что будете выполнять (незаметно) лучше, это верный способ сделать это. Принцип DRY так же применим к XAML, как и к любому другому виду разработки программного обеспечения.

Answer 2

Между этими двумя подходами есть некоторые различия, но я думаю, что два фактора уменьшат разницу между ними:

• цель привязки должна в конечном итоге учитывать все события изменения свойств на всем пути, используя любой подход
• оценка пути привязки является лишь частью гораздо большей подсистемы привязки

Это, вероятно, похоже на различия между переоценкой путей свойств в языке программирования, таком как C #. Использование временной переменной может повысить производительность, а может и нет.

В результате я бы предложил организовать как XAML, так и C # с целью удобочитаемости и удобства обслуживания вместо производительности, по крайней мере, в этом отношении. Повторять базовый контекст данных вы найдете утомительно, если вам придется делать это слишком часто, и это сделает XAML загроможденным. Это хорошая ситуация для косвенного использования свойств через новый контекст данных.