はじめに
忘れないように戒めの覚え書き。
以下、すべて独学のオレオレ MVVM で、原理原則から逸脱している部分もあるはず...
あくまで個人的にはですが、使えるなら細かい定義は気にしない考えでいます。
本文
MVVM とは
"Model", "View", "ViewModel" の頭文字をとって "MVVM" で、描画ロジックとビジネスロジックを切り分けるための手法の一つです。WPF や UWP など最近の Microsoft の開発プラットフォームでは、このデザインパターンの適用を前提としているようです。
※それ以前の Windows Forms などではイベントドリブン方式が推奨されていました。ロジック同士が癒着しがちですが、努力である程度は解消でき、直感的なコードになるため追いやすい点が長所だと思います。
| 階層 | 依存関係 | 役割 |
|---|---|---|
| Model | - | データを保持するオブジェクトと単体で動作する処理 |
| ViewModel | Model | 画面に表現されるデータの実体とコマンド |
| View | ViewModel, Model | ViewModel, Model が保持するデータの表示と機能の提供 |
出典：Prism 5 - Developer's Guide to Microsoft Prism Library 5.0 for WPF
Model
独立したデータや単体で動作するロジックが置かれる層です。
DAO やエンティティや API コマンドなど、ビジネスロジックを構築するうえで必要になる要素を納めます。そのほかコネクション確立や API 通信をサービスクラスとして独立させ置いたりもしています。
ViewModel
UI に表現されるデータや実行されるコマンドの保管庫となる層です。
原則として、ViewModel は Model を参照しますが、View を直接参照してはいけません。どのように描画するかは View に任せる格好になります。もちろん View を意識した実装になることは問題ありません。描画ロジックが割り込まないため、単体テストの自動化がしやすくなります。
怒られるかもしれませんが、上記の原則を守っていれば実装に制約はないと考えています。ViewModel はウィンドウと１対１になる場合もあれば、ウィンドウ内の登録フォームや検索条件欄に対応する場合もあります。ただし ViewModel は幅を利かせ過ぎて肥大化することもしばしばです。Model と作業分担するなり、汎用処理はサービス化するなり工夫が必要です。
View
ウィンドウやユーザーコントロールが配置される所謂 UI 層を指します。
ViewModel で宣言されたプロパティやコマンドをバインド（紐づけ）させて機能を実装していきます。ロジックは一切書かないのか？といえば決してそうではなく、フォーカス制御やアニメーションなどの描画ロジックはこの層に記述します。
View を語るうえでいつも議論になるのが「コードビハインドでの実装を許すかどうか」という問題で、無理せずに解禁して良いというのが私の考えです。原理原則を貫くことは大切ですが、それによって極端に複雑化する場合は、分かりやすさを優先したいです。（なんでもここに書いて良いとは言ってません！）
おわりに
MVVM の定義と各層の役割をまとめました。
このデザインパターンに当てはめるのは、初めてでは結構キツイと思われます。とりわけイベントドリブンに慣れていると、その経験が悪い意味の先入観をもたらし、習得をより難しくさせます。
しかしながら、構築を補助するフレームワークも存在しており、以前に比べれば実装のハードルは下がってきていると感じます。実装方法がつかめれば、ロジックの分離による開発やテストの容易さなど、徐々に恩恵が受けられるようになっていくでしょう。
とりあえずここまで。
細かい要素とか MVVM フレームワークとか DI については別の機会で。