<p>Il n’y a en realite qu’un seul nom en XAML, le <code>x:Name</code>. Un framework, tel que WPF, peut optionnellement mapper l’une de ses proprietes au <code>x:Name</code> de XAML en utilisant le <code>RuntimeNamePropertyAttribute</code> sur la classe qui designe l’une des proprietes de la classe comme correspondant a l’attribut x:Name de XAML.</p>
<p>La raison pour laquelle cela a ete fait est de permettre aux frameworks qui ont deja un concept de “Name” au runtime, comme WPF. Dans WPF, par exemple, <code>FrameworkElement</code> introduit une propriete Name.</p>
<p>En general, une classe n’a pas besoin de stocker le nom pour que <code>x:Name</code> soit utilisable. Tout ce que <code>x:Name</code> signifie pour XAML est de generer un champ pour stocker la valeur dans la classe code-behind. Ce que le runtime fait avec ce mappage depend du framework.</p>
<p>Alors, pourquoi y a-t-il deux facons de faire la meme chose ? La reponse simple est qu’il y a deux concepts mappes sur une seule propriete. WPF veut que le nom d’un element soit preserve au runtime (ce qui est utilisable via Bind, entre autres choses) et XAML a besoin de savoir quels elements vous souhaitez rendre accessibles par des champs dans la classe code-behind. WPF lie ces deux elements en marquant la propriete Name comme un alias de x:Name.</p>
<p>A l’avenir, XAML aura davantage d’utilisations pour x:Name, comme vous permettre de definir des proprietes en faisant reference a d’autres objets par leur nom, mais dans les versions 3.5 et anterieures, il n’est utilise que pour creer des champs.</p>
<p>Le choix entre l’un ou l’autre est vraiment une question de style, pas une question technique. Nous laisserons a d’autres le soin de faire une recommandation.</p>
<p>Voir aussi <a href="https://stackoverflow.com/questions/4605777/automationproperties-name-vs-xname">AutomationProperties.Name VS x:Name</a>, AutomationProperties.Name est utilise par les outils d’accessibilite et certains outils de test.</p>
