WPFとMVVMにおけるModelの役割について

Question

どこかにきちんと

• View
• ViewModel
• Model

に分割されたWindowsアプリのサンプルなどないでしょうか？
どこを探してもModelが省略されてて存在意義が現状理解できておりません。
一応以下は見つけましたが、SPAであることもあると思いますが
ViewModelと分割する意義が腑に落ちません。
https://logicalbeat.jp/blog/15425/

Answer 1

どこを探してもModelが省略されてて存在意義が現状理解できておりません。

そうですか？
MVVMを説明する以上、形だけでもModelがあるほうが多くないですか？
まあ「プロパティが１，２個あるだけでロジックも何もない」ことがほとんどですが^^;

MVVMの説明ではどうしてもViewModelが中心で、MVVMに特有でない部分（Model）が流されがちなのは仕方がないのかなと思います。

提示ページにも下記のような記述があります。

また今回は簡易的なツールなので、最小限の実装しか行っておりませんが、
本来はこのModel階層に保存処理などの実装を行います。

「実際はファイル入出力とかいろいろあるよね～」というのをくみ取ってあげてください^^

とはいえ例がないとイメージができないでしょうから、こちらなんかはどうでしょうか？
WPFでなくMAUIですが、イメージはつくと思います（提示ページとアプリ内容も似ています）
チュートリアル: MVVM ツールキットを使用して Notes アプリを更新する - .NET MAUI | Microsoft Learn

３段階でMVVM化する面白い例なので、出来れば最初からやっていただきたいです。

1. コードビハインド
2. Model-View（データバインド）
3. MVVM

チュートリアル: .NET MAUI アプリを作成する - .NET MAUI | Microsoft Learn
maui-samples/8.0/Tutorials at main · dotnet/maui-samples

Comments

[TN8001]

もっと大規模な公式（や準公式）のサンプルもありますが、大きすぎてもイヤですよね？^^;

Answer 2

Windowsアプリの新しいものとしてはWinUI等のプロジェクトテンプレートが参考になるかと思います。サンプルとは違うので実用ケースが想定しづらいかもしれませんが・・・。（１年ほど前にTemplateStudioを触ったとき記憶で書いてるので相違があったらすみません）

https://github.com/microsoft/TemplateStudio

TemplateStudioで生成したプロジェクトは基本構成がMVVMなのはもちろんのこと、Modelにあたる Core がViewのプロジェクトとは別プロジェクトとして整理されている点が特徴的です。

Coreプロジェクトには Contracts（契約を意味する）名前空間となるフォルダがあり、ここにModelとして実装すべき内容を宣言する interface を置きます。View側のプロジェクトはそのContracts名前空間にある interface を主に参照し実装の詳細についてわからないが interface が提供する機能だけ見える状態でViewを実装していくことを想定しています。いわゆる「関心の分離」というやつです。

Coreプロジェクト内に、アプリとして表現すべき特有のデータ構造であったり、モノの単位をプログラムで表現したものであったり、ファイルやサーバーにファイルを保存するための流れを記述していたりと、Modelとして「アプリの見た目以外の全て」を実装していくことになります。

また、Modelを考える際の指針としてはドメイン駆動設計（DDD）を勉強してみると具体例がよく見つかりわかりやすいと思います。ネットの記述には事務関係が多いですが、Modelに特化した考え方として比較的明文化されていると思います。

個人的な体験としては、ViewModelの実装がぶくぶくと太っていくような「ViewModelから処理やデータを切り出さないと整理がつかないぞ」と気付いたタイミングがModelについて理解が深めようとしたきっかけでした。なのでとりあえずViewModelに全部突っ込んで実装してみると何かわかるかもしれません。

Answer 3

ModelとviewModelを分割する理由を説明すればよいのでしょうか。
実際、Modelという言葉自体いろいろな解釈があり、Modelの中にビジネスロジックがある場合もあります。

ただこれは関心の分離に反していて、
どうすればよいかというとModel自体にはinsert,UpdateなどのシンプルなAPIを提供したり、カラムのデータ型だけを定義するだけでよいです。
(Modelがテーブルの写像である場合)

userテーブルやpostテーブルがあると仮定したとき、画面によってはuserテーブルとpostテーブルをそれぞれ扱い、insertやupdateを使い分けないといけない場合もあるだろうし、ほかの画面ではuserテーブルだけ、postテーブルだけを更新する可能性があります。
これをUserModelなどModelに書いてしまうと責任があいまいになりますが、viewModelに分離しModelにビジネスロジックを記載しないことで、より処理の変更などに対応しやすくなるでしょう。(処理内容が大きくなればなるほど処理を分離することは有用でしょう。)

ただ、viewModelだって常にテーブルを参照したいわけでもなく、ほかのビジネスロジックを書きたいだろうから、本来はリポジトリパターンを使用しこちらでModelを使うことを推奨します。

ただ何の決まりもないならMVVMに従わなくてもいいとも思います。
Modelが省略されていることが多いのは、ただのテーブルの写像でありテーブルの情報が定義されているだけでつまらない例だからでしょう。
あるいはModelの意味が人によって違うので意味を明確にしたくないか。

windowsアプリの場合データテーブルらへんがいろいろ提供してくれるおかげでより重要性が低く感じるかもですね。

viewはただuiを描画し
modelはただデータを持ち
viewmodelはそれぞれを柔軟に扱うことができる
それだけな気がします。

Comments

[utm.]

ちなみにMVVMのキモはデータバインディングでMVCとの1番の違いでもあります。

Viewの情報とModelの情報がバインディングにより常に一致することで、情報の齟齬が起きるタイミングがありませんし、セレクトの結果を即反映したりアップデートしたいユーザー入力も一元管理することができます。
また、必要なデータ加工はViewModelにて行えます。