🧩 MVVM（Model-View-ViewModel）
✅ このスタイルの概要
View と ViewModel をデータバインディングで結びつけ、状態と振る舞いを ViewModel に集約する UI 構造スタイル。
WPF / SwiftUI / Vue / React+状態管理 などと相性が良い。
✅ 解決しようとした問題
MVP まで来ても、次のような課題があった：
- View と Presenter のやりとりが「メソッド呼び出しの嵐」になりがち
- UI フレームワークに備わったデータバインディング機構を活かし切れていない
- 状態と描画の同期が煩雑
MVVM は、
「ViewModel が状態と振る舞いを持ち、View はそれをバインディングして描画する」
ことで、宣言的 UI と状態管理 を両立しようとする。
✅ 基本思想・ルール
● View
- 画面（XAML, SwiftUI の View, Vue/React のテンプレートなど）
- 可能な限りロジックを持たず、ViewModel のプロパティ／コマンドにバインド
● ViewModel
- 画面に必要な状態（プロパティ）を保持
- ユーザー操作を Command やメソッドとして定義
- Model / Domain と連携して状態を更新
● Model
- ドメインモデルやデータアクセス層
MVVM のキモ：
- UI フレームワークの データバインディング機能 を前提に設計する
- ViewModel はフレームワーク非依存に近い形で記述できる（理想形）
✅ 得意なアプリケーション
- WPF / UWP / MAUI など XAML 系
- SwiftUI / Jetpack Compose など宣言的 UI
- Vue / React + 状態管理ライブラリ も思想的には近い
特徴：
- 画面ごとの ViewModel が自然な単位になりやすい
- UI 状態のテストがしやすい
- データフローを整理しやすい
❌ 不向きなケース
- バインディング機構が弱い or 存在しない UI フレームワーク
- ごく簡単な画面だけの小規模ツール（MVVM の構成コストが高い）
また、実務では：
- ViewModel が肥大化しやすい
- どこまでを ViewModel に持たせるか線引きが難しい
といった課題もある。
✅ 歴史（系譜・親スタイル）
- WPF の登場とともに注目されたパターン
- MVP からの発展として、データバインディングに最適化
- 現代の宣言的 UI フレームワークでも、似た思想が再発明されている
✅ 関連スタイル
✅ 代表的なフレームワーク
MVVM は、データバインディングを備えた UI フレームワークと特に相性が良いスタイルである。
-
WPF / UWP / .NET MAUI（XAML 系）
XAML のデータバインディング機構と ViewModel の組み合わせは、MVVM の代表的実装として知られている。 -
Vue（Options API）
data/computed/methodsを ViewModel として捉え、テンプレートとバインディングする構造は MVVM 的な性質を持つ。 -
Angular
Component（ViewModel 的役割）とテンプレートのバインディングにより、MVVM に近い構造になる。 -
React + 状態管理（MobX など）
コンポーネントを View と捉え、状態管理ライブラリを ViewModel 的に扱う構成も MVVM に近い発想と言える。
✅ このスタイルを支えるデザインパターン
MVVM の中核は「状態とバインディング」であり、それを支えるパターンは次の通り。
-
Observer
ViewModel のプロパティ変更を View に通知し、自動的に再描画させる。 -
State
画面の状態（表示モード、入力内容、エラー状態など）を ViewModel 内で明示的に管理する。 -
Command
ユーザー操作（ボタンクリックなど）をコマンドとして定義し、View から ViewModel のロジックを呼び出す仕組み。 -
Mediator
複数の ViewModel や Model の間での調整役として使われることがある。
✅ まとめ
MVVM は、
- データバインディング
- 宣言的 UI
- テスト可能な UI ロジック
を両立させるための強力なスタイルである。
ただし、ViewModel の責務を適切に分割しないと肥大化しやすいため、
「ViewModel に何を持たせるか？」という設計判断が重要になる。