導入
WPFアプリを素朴に書くと、ボタンのクリックイベントの中にビジネスロジックやデータ操作を直接書いてしまいがちです。これでは画面がないとロジックを1行もテストできません。MVVM（Model-View-ViewModel）は、この問題を「役割を3つに分ける」ことで解決する設計パターンです。
説明
flowchart LR
U["ユーザー操作"] --> V["View<br/>（XAML・見た目）"]
V <-->|データバインディング| VM["ViewModel<br/>（画面の状態・操作）"]
VM -->|呼び出す| M["Model<br/>（Entity・Service など業務ロジック）"]
M -->|結果を返す| VM
- Model: 業務データとルールそのもの（これから作る
TaskItem・TaskServiceなど）。画面のことは一切知らない。 - ViewModel: 画面の「状態」（一覧・入力中の文字など）と「操作」（追加・完了などのコマンド）を、UIフレームワークに依存しない普通のC#クラスとして表現したもの。Modelを呼び出し、結果をプロパティとして公開する。
- View: XAMLそのもの（見た目）。ロジックはできるだけ書かず、ViewModelのプロパティにバインドし、ユーザー操作をコマンドとしてViewModelへ伝えるだけにする。
デザインパターンコースのMVCと比べると、MVCのController相当をViewModelが担いますが、MVVMではView⇄ViewModelの同期の多くをデータバインディングの仕組みが自動で行う点が大きな違いです（詳しくは第7章）。
このコースがブラウザだけでMVVMを学べるのは、ModelとViewModelは普通のC#クラスであり、WPFの画面が無くてもコンパイル・実行・テストができるからです。実際のWPFのView（XAML）に接続するのは第7章から。それまでの章は、画面のことを考えずにModelとViewModelを鍛えることに専念します。
まとめ
- MVVMはModel（業務ロジック）・View（見た目）・ViewModel（画面の状態と操作）に役割を分ける
- View⇄ViewModelはデータバインディングで同期する
- ModelとViewModelは普通のC#クラスなので、画面が無くてもテスト・実行できる
次回: 実務のプロジェクト構成 ― MyApp / MyApp.Core / MyApp.Infrastructure / MyApp.Tests を見ていきます。