[MVVM] ViewModelとModelは一対でなければなりませんか？

Question

質問内容

MVVMではViewModelとModelは一対でなければなりませんか？
ViewModelから複数のModelを参照することはルール違反でしょうか？

詳細

MVVMの学習を行っています。
ネットにあるサンプルの場合、View - ViewModel - Model が一対となっている説明が散見されます。
ファイル構成でいうと、

View	ViewModel	Model
MainView.xaml	MainViewModel.cs	MainModel.cs

このような感じです。

私もはじめこの構成でもってプログラミングを開始したのですが、今現在MainModel.csが肥大化し続けています。
機能レベルでクラスの分割は行っておりますが、それらオブジェクトのインスタンスをMainModel.csが抱えてしまっているため、機能追加の度にMainModel.csが大きくなります。
（要するにMainModelが全ての機能をラップした神オブジェクトになってしまっている感じです。。。）

/*
[現行]
 View --- MainViewModel --- MainModel --- 機能A
                                      └- 機能B
                                      └- 機能C
*/

この肥大化をやめるため、以下のような構成を考えているのですがこれはルール違反ですか？

/*
[変更案]
 View --- ViewModel --- 機能A
                    └- 機能B
                    └- 機能C
*/

それとModelと呼ばれるクラスはクラス名に必ず"Model"をつけないといけないものなのでしょうか？

恐れ入りますがご意見頂戴できれば幸いです。よろしくお願いします。

開発環境

OS: Windows 10 (64bit)
開発言語: C#(WPF)
.Net: 4.6.1
IDE: VS 2017

※ 開発中のアプリケーションは、画面が1枚（細かいダイアログは除く）のアプリケーションです。

以上

Answer 1

View - ViewModel - Model が一対となっている説明が散見されます

説明しやすくするためにそうしているだけです。
1対10対100でも100対10対1でもかまいません。
と言うか、1対1対1になる事はほぼありません。
我流で作り始めるより、まずはテンプレートなりサンプルなり開いてみることをお勧めします。
「定石は学ぶよりまねろ」ですよ。
Prism Template Packがお勧めです。

Comments

[g_uo]

ご回答ありがとうございます。
Prismは導入しているのですが、Templateは知りませんでした。。。もっと早く質問しておけばよかったです。
>「定石は学ぶよりまねろ」ですよ。
この精神でネットのHow Toを真似てみたつもりでしたが、完全に調査不足でした。
真摯に受け止め精進します。ご指摘ありがとうございます。

hihijiji様のおっしゃるように、1対1対1は実際のコーディングに存在しないと思います。であれば、ネットのサンプルもそのような方向で充実していけば、MVVMがより普及するように感じます。
よければhihijiji様のご意見を伺ってみたいです。

[hihijiji]

万人に対して完璧なサンプルを作るのは不可能だと考えております。
私の信条としましては、一つの傑作を参考にするより十の良作を、十の良作より百の凡作を参考にするようにしています。
私自身MVVMインフラは、MVVM Light toolkit → Livet → Prism と使ってきましたが、全て傑作だとおもいます。
MVVM Lightでは扱いやすさに感動し、Livet では開発効率の高さに感激し、Prism では完成度の高さに感銘を受けました。
MVVMインフラを変遷したことはけして無駄ではなく、それぞれ身になったと実感しております。

[g_uo]

早速のお返事ありがとうございます。
大変勉強になります。
hihijiji様の取り組みを参考に、今後とも様々なインフラを学習しつつMVVM、および言語の習得に努めようと思います。
年始早々ありがとうございました。

他の皆様方も、自身のお考えがおありでしたらコメントいただければ幸いです。

Answer 2

補足ですが、Modelを機能で分類したら、ViewModelやViewも必要に応じて機能に応じた分類をしたほうが良い場合も多々ある気がします。

Comments

[g_uo]

omanuke様
ご回答ありがとうございます。
重ね重ね初歩的な質問で恐縮なのですが、Viewを分割するというのは画面をユーザーコントロールで分割していくということでしょうか？
もし具体的な事例や、認識の違いに対するご指摘があればご教示いただけないでしょうか。
よろしくお願いいたします。

[omanuke]

ユーザーコントロールというのはボタンやエディットボックス的なものを指してますか?
ここで言ってるのはもう少しそれらが組み合わさってできた画面となるものを指してます。
例えばカラムタイプのツイッタクライアントなどを例に考えてみます。
複数のカラムが表示され各々のカラムにはカラムを編集する削除するなどのボタンなりメニューがあり、入力してツイートボタンを押せばツイートできるエディットボックス的なものが常に画面下部に表示されているとします。

それらをひとつのおおきなViewModelで処理することもできますが、だったらカラムごとに一つのViewModelがあり、そのカラムを表示するViewがあり入力とツイートを処理するViewModelとそれに対応したViewがあり、それらをまとめるViewModelとそれらViewをまとめて表示する全体のViewがある方が全体の見通しがよくなりませんかね?

いずれにしてもMVVMはただのドメインとビューを分割する考えであってその根本は適切に内部を分割するというだけです。
であったら、原理原則などにこだわらず、自分が必要だと思う分割をやってみてもいいのではと思います。
そうしたうえでああやっぱりこういう分割をしたら又はしなかったらこういう時に困るとかこれはやらなくていいんじゃないかとかつかめてくると思います。
場合によっては全体をまとめるViewやViewModelやそれに対応するModelなどは必要なかったりもするかもしれません

[g_uo]

丁寧なご回答、まことにありがとうございます。
示していただいた例は、文章だけでも全体の構成が理解でき、見通しのよい構成であると感じました。

改めて考えてみて、omanuke様のご意見をWindowFormのアプリケーションに当てはめて考えると大変しっくりと理解できました。（私がWindowFormの経験がほとんどであるため）
ご指摘のとおり、MVVMという概念に固執しすぎていたようです。
画面をパーツごとに分割して実装することはWindowFormでは普通に行っていたことでした。それをWPFやMVVMなどの新しい取り組みのなかで、自分の知識不足を棚に上げて情報不足を嘆いていただけだったように思います。

他の回答者様からもご指摘頂戴しておりますが、もっと学習をしっかりと行いたいと思います。
また機会がありましたらご助力のほど、よろしくお願いします。
お忙しい中ありがとうござしました。

Answer 3

機能は分割すべきです。
命名規則は自由です。
サンプルの場合は読み手にわかりやすくするために Model ということを強調した名前をつけているんだと思います。

Comments

[g_uo]

ご回答ありがとうございます。
Modelも分割すべきなのですね。分割する方向でリファクタリング進めます。