警告
この記事は著者の浅い経験からの憶測をぶちまけただけのポエムであり、
信じるか信じないかはあなた次第です。
View
自動テスト不能なコントロールの配置などの見た目にまつわる部分(UIロジック)が記された層
ViewModel
テキストボックスなどのバリデーションや
データの変換、
Viewの状態(wpfでいうところのListBoxに表示しているObservableCollectionの内容)など
のロジックをUIロジックから分離して単体テスト可能にするための層。
要はUIロジック中の自動テスト可能なロジックを分離した"プレゼンテーションロジック"が記された層。
Model
DBへの操作や登録数の上限を超えないか？などのロジック(ビジネスロジック)が記されるサービスクラス群
メモ
DDDのアーキテクチャ関連の記事なんかでは
ビジネスロジックレイヤーとDB操作やWeb API操作などの
特殊な技術を取り扱う層を別のインフラ層として分離したほうが
ごちゃまぜにならず済むという意見もあるようです。
ただ1つのソリューションの中に
- View/ViewModel用プロジェクト
- Model用プロジェクト
- 複数のインフラ層用プロジェクト
全体で三層+複数のインフラ層となるとかなり念入りな設計が必要っぽいですね。
この時点でスピーディーさには難がある開発手法のようです。
考察
ガチガチに自動テストを行わないようなラフなプロジェクトや
堅実さよりスピーディーさが求められる小さなプロジェクトでは
いたずらに開発に時間がかかるだけなので、昔ながらのコードビハインドを使った
イベントドリブンな開発ほうが楽そうです。
逆にMVVMが有効な状況はこと細かくすべての
プレゼンテーションロジック
ビジネスロジック
特殊な技術
の挙動を自動テストできるようにせねばならないプロジェクトや
非常に巨大になることが予想されており
どこに何が書かれているか推測できる用にしたいプロジェクトでは
有効に働くかと思われます。
MVVMパターンは決して銀の弾丸などではなく
開発コストと堅実さ(パターンの崩壊を防いだりどこになにが書いてあるかすぐ理解できるような状態やUI以外のロジックをテスト可能にしたりDIパターンを駆使して下位レイヤーなしで上位レイヤーをテスト可能にしたりできる状態)どちらを優先すべきかを天秤にかけて選ばなければ
いつまでたっても開発が終わらない/どこに何が書いてあるかわからない/テストがほぼできておらず予想外な挙動をする実装だらけというような状況に苦しめられかねないので最強の開発手法ではないと肝に銘じる必要があります。
上記の理由から私は個人で開発する小規模な趣味開発のアプリではMVVMを使用すべきではないのではないと考えてます。
コードビハインド+インフラ層とごちゃまぜのビジネスロジック層あたりがちょうどよいのではないでしょうか。
ビジネスロジック層を残したのはコードビハインド中に
SQLクエリを書くと後々混乱しそうだからです。