1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MVVMを意識していたのに、WPFのViewModelが壊れ始めた話

1
Last updated at Posted at 2026-02-15

WPF開発では、MVVMを前提にした設計がよく語られます。
自分自身も、これまでの案件で
「View と ViewModel を分けること」
「ロジックは ViewModel に寄せること」
を意識して実装してきました。
ただ、実際の現場では
MVVMを意識していたはずなのに、
気づくとViewModelがどんどん苦しくなっていく
という経験をしました。

前回の記事では、WPF開発で最初に意識しておきたかった設計の考え方を整理しました。
今回はその続きとして、
現場で実際にMVVMが揺らいだ瞬間と、
そのとき自分がどう判断したかを振り返ってみます。

1. 最初はちゃんとMVVMを意識していた

プロジェクト初期は、MVVMを強く意識していました。
View には画面表示とUI制御のみを書く
業務ロジックや状態は ViewModel に集約する
操作は Command 経由で呼び出す
いわゆる「教科書的なMVVM」です。

画面数も少なく、要件もシンプルだったため、
この段階では
「ちゃんと分けられている」
「このまま進めば問題なさそう」
と感じていました。

2. いつの間にかViewModelが苦しくなり始めた

機能追加や画面追加が進むにつれて、
少しずつ違和感が出てきました。
・Commandの数が増え続ける
・UI状態を表すプロパティが増える
・View専用に見えるプロパティが混ざり始める

具体的には、
「ボタンの活性・非活性」
「表示・非表示の切り替え」
といったUI都合の状態が、
いつの間にか ViewModel に集約されていました。

その結果、ViewModelは
業務ロジックとUI制御が混ざったクラスになり、
後からコードを読むコストが一気に上がっていきました。

たとえば、
一覧画面で以下のような制御が必要になったケースです。

・選択中のアイテムがあるかどうか
・編集モードか閲覧モードか
・条件によってボタンの表示・非表示を切り替える

最初は
「すべて状態管理だからViewModelで持つべき」
と考え、
以下のようなプロパティを次々に追加しました。

・IsItemSelected
・IsEditMode
・IsSaveButtonEnabled
・IsDeleteButtonVisible

一つひとつは正しく見えますが、
機能追加が進むにつれて
UI制御用のプロパティがViewModelの大半を占める
状態になっていきました。

結果として、
業務ロジックがどこにあるのか分かりづらい
画面を触らない人がViewModelを読むのがつらい
修正時に影響範囲を追いづらい

といった問題が出てきました。

この経験から、
明らかに画面専用の状態まで
無理にViewModelへ集約しない
という割り切りをするようになりました。

3. 悩んだポイント:どこまでをViewModelに持たせるか

ここで一番悩んだのが、
どこまでをViewModelに持たせるのが正しいのか
という点です。

Viewに残すと
「MVVM的に良くないのでは?」
と感じる一方で、
すべてをViewModelに寄せると
UI都合のコードが増えていきます。
調べれば調べるほど、
「正解は1つではない」
ということに気づきました。

MVVMはルールではなく、現場で使うための考え方
なのだと、このとき強く感じました。

4. そのとき自分が取った“割り切り”

最終的に自分が意識するようになったのは、
完璧な分離よりも、チームで読みやすいことです。

明らかに画面専用の状態は View に寄せる
業務的な意味を持つ状態は ViewModel に残す
境界が曖昧な部分は、チームで共有する
「これはViewModelで持つべきか?」

迷うポイントほど、最初に言語化しておくこと
が後半の修正を楽にしました。

5. 今ならこう考える、MVVMの境界

今振り返ると、
MVVMで一番大事なのは
分けること”そのものではなく、
“迷ったときの判断軸を持つこと

だと感じています。
誰がこのコードを読むのか
半年後に修正するのは誰か
変更はどれくらい入りそうか
こうした視点で考えることで、
MVVMは現場にフィットする形になります。

おわりに

MVVMは、守るためのルールではなく、
現場を楽にするための手段だと思っています。
最初に少し立ち止まって
「どこまでをViewModelに持たせるか」
を話しておくだけでも、
後半の開発や保守はかなり楽になります。

WPFは自由度が高い分、
最初の判断がそのまま負債にもなりやすい技術
です。

だからこそ、
完璧よりも“続けられる設計”を
意識していきたいと感じています。

関連記事(内部リンク)

WPF開発で最初に知っておきたかったこと
WPFで後から辛くなるバインディングの典型パターン3選
WPFでよくあるCommandハマりポイント3選+回避策【初心者でも安心】

1
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?