WPFではUIを構築する方法として、
コードビハインドによるイベントドリブンと
データバインディングという2つの考え方があります。
この2つは対立するものではなく、役割が異なる仕組みです。
また、どちらか一方だけでもアプリケーションを作成することは可能です。
ただしWPFは、ある程度規模の大きいアプリケーション開発で採用されることが多いため、
そのようなケースではロジックとUIを分離する目的で
データバインディングを中心とした設計が採用されることがあります。
では、コードビハインドは全く不要かと言うと、
残念ながらそうでもありません。
UIを操作する細かな動作など、
Viewの内部で完結させるべき処理も数多く存在します。
例えば次のようなものです。
- UIコントロールの細かな状態制御
- フォーカス操作
- レイアウト調整
- ドラッグ操作などのマウスイベント処理
- View固有の表示ロジック
これらはアプリケーションロジックではなく、
そのため、このような処理まで
このようなケースでは、
この構造はWebに例えると以下のような関係になります。
つまり、WPFのUIは XAML + コードビハインド だけでも
WPFの基本的なプログラミングモデルはイベントドリブンです。
例えばボタンが押された場合は次のようになります。
また、コードビハインドでは以下のようなことも自由に行えます。
ただし、このような動的UI操作は後述するデータバインディングと相性があまり良くありません。
アプリケーションロジックやビジネスロジックを
データバインディングは次の仕組みです。
この2つを自動的に連動させる仕組みです。
この場合、C#側には次のようなプロパティが存在します。
WPFのバインディングは
つまり次のような構造です。
ここで重要なのは、
XAMLは単なる文字列としてプロパティ名を書いており、
そのため、XAMLとC#は互いの存在を直接知らない構造になっています。
バインディングのデータソースは通常
DataContextには通常のC#クラスのオブジェクトを指定できます。
ただし、UIを自動更新するには
これにより、プロパティが変更されたときにUIへ通知されます。
ボタンのクリックなど、
特徴的なのは、 XAML側
このようにすることで、
コードビハインドとデータバインディングは
WPFではこの2つを理解することで、
純粋にUIの振る舞い
データバインディングだけで解決しようとすると、
本来UIに属する処理がViewModel側へ流れ込み、
設計が歪んでしまう
コードビハインドで処理を書く方が自然な設計になります。
WPFの基本構造
完結したアプリケーションを作ることが可能です。
コードビハインドによるイベントドリブン
private void Button_Click(object sender, RoutedEventArgs e)
{
MessageBox.Show("Hello WPF");
}
データバインディングの役割
UIから分離して管理したい場合に使われるのが
データバインディングです。
Text="{Binding UserName}"
public string UserName { get; set; }
バインディングは名前で接続される
名前（文字列）で接続されます。
お互いが直接参照しているわけではないという点です。
WPFのバインディングシステムが実行時に接続しています。
DataContextとバインディング元
WindowのDataContextになります。
this.DataContext = new MainWindowViewModel();
INotifyPropertyChangedを実装する必要があります。
public class ViewModel : INotifyPropertyChanged
ICommandによるアクションのバインディング
ユーザー操作をトリガーに処理を実行したい場合
データバインディングでは ICommand を使います。
処理なのにメソッドではなくプロパティとして扱う点です。
public ICommand SaveCommand { get; }
Button Command="{Binding SaveCommand}"
ボタン操作とC#側の処理をバインディングで接続できます。
まとめ
どちらか一方だけを使うものではなく、目的に応じて使い分ける仕組みです。
UI設計の自由度が大きく広がります。
コメント