は私が継承されてきた複雑なWPFのUI

Question

WPFアプリケーションを作成するためのより良い方法を見つけることのようなパターンは次のXAMLにかなりの量含まれています。我々は、UI部分のUserControlでグループ化されている、言い換えれば

<Window ...> 
    <Grid> 
     <z:SomeUserControl> 
      <z:AnotherUc> 
       <Label /> <Button /> <ComboBox /> 
      </z:AnotherUc> 
      <z:AnotherUc> 
       <Label /> <Button /> <ComboBox /> 
      </z:AnotherUc> 
     </z:SomeUserControl> 
    </Grid> 
</Window> 

を、多くの場合、他のUserControls内にネストされます。ある時点で、コンテンツは基本的なWPFコンテンツコントロールを使用して定義されます。

我々が対処しようとしている問題は、Xということです：Name属性は、悪名高いWPFの制限のために最も内側のコントロールのいずれにも適用することはできません。

Cannot set Name attribute value {0} on element {1}. {1} is under the scope of element {2}, which already had a name registered when it was defined in another scope

これは、コードビハインドがUserControl内の要素を参照できる必要があるため、問題が発生します。 UserControlsはUIの一部をグループ化するために選択されました。なぜなら、デフォルトコントロールのすべてのスタイリングとテンプレート化は、あまりにも邪魔にならず、マークアップがすぐに恐ろしい、判読不能な混乱につながったからです。

ただし、マイクロソフトがこの「制限」を解決する意図がない場合は、より良い方法を見つける必要があります。接続サイトでGaryGJohnsonの回避策に見られるように、CS +外部XAMLテンプレートファイルを使用することが検討されています。しかし、これはsphagettiの感情を持っており、バインドを中断するものは何もない。

Answer 1

ここでの最適なオプションは、通常、これらの「内部」要素にコードを使用しないようにすることです。引き続きデータバインディングを使用することができるので、DataContextのプロパティにこれらをバインドすると正しく動作します。

もう1つの方法はもちろん、ラベル/ボタン/コンボボックスを直接AnotherUcクラスの依存関係プロパティとして公開することです。これにより、スコープの問題を回避するUserControlのメンバーとして直接使用することができます。

もちろん、これの欠点は、コントロールを配置する代わりに、要素の特定の組み合わせに対してユーザーコントロールをカスタマイズする必要があることです。

Answer 2

デザイン上の混乱のような音です。独自のAttachedProperty - MyNamePropertyを作成し、XAMLで設定し、独自の論理/ビジュアルツリーヘルパーを作成することができます。私はそれを行うと言っているわけではありませんが、迅速な回避策が必要な場合（UI構成モデルの根本的な再設計を伴って）、それがあなたのことをするかもしれません。