どこかにきちんと
- View
- ViewModel
- Model
に分割されたWindowsアプリのサンプルなどないでしょうか?
どこを探してもModelが省略されてて存在意義が現状理解できておりません。
一応以下は見つけましたが、SPAであることもあると思いますが
ViewModelと分割する意義が腑に落ちません。
https://logicalbeat.jp/blog/15425/
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答3件
0
どこを探してもModelが省略されてて存在意義が現状理解できておりません。
そうですか?
MVVMを説明する以上、形だけでもModelがあるほうが多くないですか?
まあ「プロパティが1,2個あるだけでロジックも何もない」ことがほとんどですが^^;
MVVMの説明ではどうしてもViewModelが中心で、MVVMに特有でない部分(Model)が流されがちなのは仕方がないのかなと思います。
提示ページにも下記のような記述があります。
また今回は簡易的なツールなので、最小限の実装しか行っておりませんが、
本来はこのModel階層に保存処理などの実装を行います。
「実際はファイル入出力とかいろいろあるよね~」というのをくみ取ってあげてください^^
とはいえ例がないとイメージができないでしょうから、こちらなんかはどうでしょうか?
WPFでなくMAUIですが、イメージはつくと思います(提示ページとアプリ内容も似ています)
チュートリアル: MVVM ツールキットを使用して Notes アプリを更新する - .NET MAUI | Microsoft Learn
3段階でMVVM化する面白い例なので、出来れば最初からやっていただきたいです。
- コードビハインド
- Model-View(データバインド)
- MVVM
チュートリアル: .NET MAUI アプリを作成する - .NET MAUI | Microsoft Learn
maui-samples/8.0/Tutorials at main · dotnet/maui-samples
投稿2024/09/07 08:17
総合スコア9713
0
Windowsアプリの新しいものとしてはWinUI等のプロジェクトテンプレートが参考になるかと思います。サンプルとは違うので実用ケースが想定しづらいかもしれませんが・・・。(1年ほど前に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に全部突っ込んで実装してみると何かわかるかもしれません。
投稿2024/09/12 14:39
編集2024/09/12 14:41総合スコア769
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
0
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はそれぞれを柔軟に扱うことができる
それだけな気がします。
投稿2024/09/07 09:37
総合スコア208
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2024/09/07 08:17