MVVMにおける、ViewModelとModelの違い、境界線について

Question

前提・実現したいこと

ViewModel(VM)とModelの区別が未だにつきません。

以下の記事のコードの例を出しますと、
サンプルコードを見ながら理解するMVVMの基礎的な実装

チュートリアルとして、Personクラスが最初にModelとして実装されています。
しかしこれでは更新されないので、INotifyPropertyChangedを実装してPersonViewModelにしています。

Modelとして実装したはずのPersonクラスが、Viewと結びつかせるためにVMになりました。
そうなるとModelとはいったい何なのでしょうか。
データを保持したり、その処理を書くのがModelだと聞きますが、上の例だとVMがModelのようにデータを保持しているように感じます。

最初は、VMとModelを完全に別にするとなると、以下のようにPersonVMクラスの中にPersonのインスタンスを作ってラップするのではないかと考えました。

PersonVM : INotifyPropertyChanged //(1)
{
    Person person = new Person();
    public int Age{
        get => person.Age;
        set {
            person.Age = value;
            NotifyPropertyChanged(nameof(Age));
        }
    }
}

しかしこのようにVMとMを分けると、Personに対して操作しても変更通知されません。

また、ReactivePropertyの意味や使い方がよくわからなくなってしまいます。

//こう書くのがReactivePropertyの使い方だと思っていたが、VMとModelを兼任しているためMVVMにはならない？
PersonVM : INotifyPropertyChanged //(2)
{
    public ReactiveProperty<int> Age{get;} = new ReactiveProperty<int>();
}

//Modelに代入させることはできても、結局Modelのインスタンス内の変更通知はVMにもVにも飛ばない。
//逆に、ModelからVMに変更通知が必要な設計が間違い？
PersonVM : INotifyPropertyChanged //(3)
{
    Person person = new Person();

    public PersonVM(){
        Age.Subscribe(x => person.Age = x);
    }
    public ReactiveProperty<int> Age{get;}= new ReactiveProperty<int>();
}

このPersonクラスをバイナリなりテキストなりでエクスポートする実装をするとして、
ViewModelのCommandの中で出力処理を書いてしまうのはNGだと聞きます。

(1)や(3)ならPersonクラスにメソッドを入れるなり、Personクラスを引数にするメソッドをどっかに作ったりとやりようがありますが、
(2)のようなパターンだとPersonVM内に作るか、PersonVMを引数にとらなくてはならなくなってしまいます。

データ出力のためにVMが必要ならば、それはVMがデータを保持している。つまりVMでもありModelでもあるという状況になっていないでしょうか。

このように、私の中でModelとVMの境目、分け方がわからなくなってしまい混乱しています。
どこかにMVVMの解釈に関して誤解がないか。また、どのような形でMVVMを実装するのが正しいのかの助言をいただきたいです。

よろしくお願いいたします。

Answer 1

混乱の原因は「ModelとViewModelに対して実装すべき「関心領域」をどう分別し、考えるべきか」がまだわからないことにあると思います。

ざっくり説明するとModelクラスは「アプリに必要なデータ構造、データ処理、そして副作用の起点となるメソッド・コマンド・プロパティ」を持たせます。

一方でViewModelクラスは「VMはVとMを繋ぐだけ。Viewに渡すModelの交通整理をするのみに留める。ViewModelはデータ処理の知識を知ってる必要がないので、特に副作用が発生するCommandをViewModelに実装するべきではないはず」と個人的に理解しています。

(2020/06/28 訂正)

ViewModelにCommandを置かないと、今度はModel側にCommandというViewの都合の一種が漏れてしまいます。Commandは極力ViewModelに置くべきです。結果的に誤った解釈を提示してしまい、すみませんでした。

この２点を理解した上で「ViewにVMを通じてModelを直接渡してUIを作っていく」とするのが一つの方針になるのかなと思います。

また、「Personクラスの出力処理をViewModelに書くのはModel的でNG、だけどどうすれば」という部分については、

• 出力処理用のModelクラスを作成（＝PersonProcesserとしましょう）（CommandParameterとしてPersonクラスを受け取れる処理用Commandを持たせる）
• ViewModelにPersonProcesserクラスのインスタンスを作成
• View上のボタンなどに、CommandとしてPersonProcesserクラスのCommand、CommandParameterとしてPersonクラスのインスタンスを設定する

といった流れで実装するのがいいのかなと思いました。

ViewModelに作成するのはPersonクラスのModelだけでなく、(PersonProcesserのような)処理を行うModelをさらに持たせて、「View上で組み合わせる」という発想によってViewModelがModel機能そのものを持つことを回避することが出来るかと思います。

---

なお、これらはMVVMフレームワークの「Prism」を使ってきた経験による理解ですので、別のMVVMフレームワークになるとまたお作法が変わってくるかもしれません。（とはいえ概念的な理解にそこまで外れてはいないと思います）

Comments

[OZONE]

いままで「VMがデータを保持してしまっているように見える」と悩んでいましたが、
「VMはViewに表示する情報を、Modelから受け取って適切な値にして一時保管している」というのが正しく、上の例で上げるのであれば、

●氏名や年齢を保持しているModelとしての「Person」クラスと、それを受け取って変換する「PersonVM」があり
●どちらも「氏名」や「年齢」など同じデータを持っていて１つのクラスで間に合わせたくなるが、保守性などを考えMVVMとする場合は二つを分離し、
●VMにもModelも変更通知の機能を持たせ、Model <-> VM <-> View の変更通知の流れを作る。

という解釈で合っていますでしょうか。
さらに言えば、上で貼ったサイトには「PersonViewModel」という命名をされていますが、
「〇〇WindowVM」のようなViewに合わせた名前のほうがより妥当なのでしょうか。

どうしても「INotifyPropertyChangedはVMが持っている」と先入観がありましたが、ModelもVMに変更通知するので、INotifyPropertyChangedを実装していても、Viewのための変換の立ち位置でなければModelであると考えてよいのでしょうか。

確認したい箇所が多いですが、ご教授よろしくお願いいたします。

[tor4kichi]

「保守性を考えて同じデータでもMとVMの２つに分離する」という点は回答で否定してる部分になります。Mのデータ構造のみに統一するべきと考えます。

　VMにMのデータ構造を余分に持たせようというのは「Mの都合をVに見せるべきではない（またその逆も然り）」という考え方からくるものと思いますが、「Vは状態を発生させる責任者でありMの都合を知っていても問題がない。逆にMはVの都合を知っていてはいけない」という「状態はVが管理する」＋「依存の一方向性」の２点の原則が重要だと思います。MがVのことを知らない設計を担保できるなら、VがMを知っている複雑さをコントロールできるはずです。

　次に、変更通知の流れとしてVとMの間にVMが挟まっている必要はないと考えます。VとMの都合をどうしても折衝する必要があるときだけVMで変換するようなことがあるかもしれません。それでも基本的にはMに起きた副作用はその副作用を起こしたMの中で完結させた上で変更通知によって（VMを介することなく）Vが更新される、という流れが理想的かと思います。

　具体的には、DataBindingのターゲットを（VM自体ではなく）VMが持つMのインスタンスのプロパティを指定することで、変更通知のやり取りからVMを省略することが出来ます。そのため（Vに変更されうる）Mは変更通知を実装していて然るべきです。

　最後に、ViewModelの命名については仰るとおりで（Microsoftが出しているMVVMフレームワークのPrismでは、）例えばMainPageに対してはMainPageViewModelと命名するのが一般的です。（MVVMフレームワークによって命名の慣習が異なるかもしれません）Prismを始めとしてMVVMフレームワークをいくつか見て回ってみるといいかもしれません。

[OZONE]

「変更通知の流れとしてVとMの間にVMが挟まっている必要はない」
「DataBindingのターゲットをVMが持つMのインスタンスのプロパティを指定する」というところで腑に落ちました。
VMにあるインスタンスは、ViewにBndingされるのであればVMだと勘違いしていたようです。
丁寧な回答ありがとうございました。

[tor4kichi]

回答で書いた「ViewModelにCommandを書くべきでない」というのは明確に間違った解釈でした。混乱を与えて申し訳ない。

（回答を書いた当初「Fat ViewModel問題を解消したい」と視野狭窄になっていたのだと思います。）

Model側にCommandを書くと、それはそれで「Viewの都合をModelが面倒を見なければいけない」という問題が起きます。

ですからViewModelでCommandを記述してViewとModelを繋ぐ役割は必要です。