Sind WPF Binding Pfade unter der Haube normalisiert?

Question

Ich frage mich nur, ob es einen Unterschied macht, wenn ich den Unterpfad zu einer Eigenschaft in jeder Bindung wiederholen oder wenn ich den DataContext binden und nur die relativen Pfade in den Bindungen angeben.

例を挙げます：

Absolute Pfade:

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

Relative Pfade:

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

Ich weiß, dass beide die gleichen Eigenschaften binden, aber ich bin daran interessiert, was wirklich hinter den Kulissen passiert, weil dies vielleicht die Leistung in Situationen beeinflussen kann, in denen es viel mehr als 2 Bindungen gibt. Führt die Variante mit absoluten Pfaden zu mehr "Event-Traffic", weil jede der Text-Bindings die ViewModel-Eigenschaft und ihre spezifische Eigenschaft beobachtet? Oder wird es genau dasselbe sein? Ich könnte mir vorstellen, dass ein BindingManager alle Bindungspfade auflöst, so dass beide Varianten in genau der gleichen IL landen.

Wenn die Struktur der Bindungshierarchie einen Einfluss hat: Hat die Verwendung des "langsameren" Ansatzes mit vollständigen Pfaden in jeder Bindung irgendwelche positiven Auswirkungen (abgesehen von den Präferenzen für den Codestil)?

Answer 1

Sobald das Bindungsobjekt instanziiert ist, spielt es keine Rolle mehr, wie aufwendig das Markup war, mit dem es erstellt wurde; das Objekt enthält einen Verweis auf die Quelleigenschaft, und wie dieser Verweis gefunden wurde, ist nicht mehr relevant. Die einzige Auswirkung auf die Leistung, die die eine Methode gegenüber der anderen hat, ist also die Instanziierung der Bindung selbst.

Sich nicht zu wiederholen, führt nicht nur zu einer (unmerklich) besseren Leistung, sondern ist auch der richtige Weg, es zu tun. Die DRY-Prinzip ist auf XAML genauso anwendbar wie auf jede andere Art der Softwareentwicklung.

Answer 2

Es gibt einige Unterschiede zwischen den beiden Ansätzen, aber zwei Faktoren, die mir einfallen, werden den Unterschied zwischen ihnen verringern:

• das Ziel des Datenflusses muss letztendlich alle Eigenschaftsänderungsereignisse entlang des Pfades berücksichtigen, wobei beide Ansätze möglich sind
• die Bewertung des Bindungspfads ist nur ein Teil des viel größeren Bindungs-Teilsystems

Dies ist wahrscheinlich vergleichbar mit den Unterschieden zwischen der Neubewertung von Eigenschaftspfaden in einer Programmiersprache wie C#. Die Verwendung einer temporären Variable kann die Leistung verbessern, muss es aber nicht.

Daher würde ich vorschlagen, sowohl XAML als auch C# mit dem Ziel der Lesbarkeit und Wartbarkeit statt der Leistung zu organisieren, zumindest in dieser Hinsicht. Die Wiederholung des Basisdatenkontextes wird als mühsam empfunden, wenn Sie dies zu oft tun müssen, und lässt die XAML unübersichtlich aussehen. Das ist eine gute Situation, um die Eigenschaften indirekt über einen neuen Datenkontext zu verwenden.