WPF のバインディングは便利で強力ですが、ちょっとした設計の違いで後から修正がとても辛くなることがあります。

私自身も最初の頃、ItemsControl 内の DataTemplate で親 ViewModel のコマンドを呼び出す という単純な実装で、後から UI をリファクタリングしたときに何時間もハマった経験があります。

「便利だからこう書いたけど、後で困った…」というパターン、意外と多いんです。
この記事では、実務でよく遭遇する典型的なハマりポイント3つを整理し、それぞれの回避策も紹介します。

典型パターン1：DataContext が深すぎる階層でのバインディング

ポイント

ItemsControl / DataTemplate 内で親 ViewModel のプロパティを参照すると辛い
RelativeSource や ElementName が多用され、修正が大変

コード例

<ItemsControl ItemsSource="{Binding Orders}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding CustomerName}"/>
            <Button Content="キャンセル"
                    Command="{Binding DataContext.CancelCommand, 
                                      RelativeSource={RelativeSource AncestorType=Window}}"/>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

回避策

ViewModel 側で子アイテムに必要なコマンドをラップして渡す
DataContext を深くしない設計を意識する

public class OrderItemViewModel
{
    public string CustomerName { get; set; }
    public ICommand CancelCommand { get; set; }
}

典型パターン2：TwoWay Binding なのに更新タイミングが合わない

ポイント

TextBox.Text のデフォルト更新タイミングは LostFocus
Command や Validation と衝突することがある

コード例

<TextBox Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"/>

回避策

UpdateSourceTrigger=PropertyChanged で即時反映を指定
文字入力中に ViewModel が最新状態になるように設計

典型パターン3：コレクションと選択状態の同期ミス

ポイント

ObservableCollection の差し替えで SelectedItem が null になる
ListView / ListBox でありがちなパターン

コード例

SelectedUser = null;
Users.Clear();
Users.Add(newUser1);
Users.Add(newUser2);

回避策

Collection を差し替えず、Clear/Add で更新
SelectedItem は明示的にリセット/設定

図解：典型パターンまとめ

深すぎるDataContext、更新タイミングのズレ、選択状態同期ミスの例

まとめ

DataContext は浅く保つ：深い階層の RelativeSource は後から辛い
TwoWay Binding の更新タイミングに注意：TextBox なら UpdateSourceTrigger を確認
コレクションと選択状態の同期は慎重に：SelectedItem の扱いを意識する

関連記事（内部リンク）

WPF開発で最初に知っておきたかったこと
 MVVMを意識していたのに、ViewModelが壊れ始めた話
 WPFでよくあるCommandハマりポイント3選＋回避策【初心者でも安心】