WPF(.NET, WinUI) GUIプログラミング Part31

**デフォルトの名無しさん** · 2023/01/22(日) 05:53:16.97

WPF(Windows Presentation Foundation)について語るスレ。

前スレ
WPF(.NET, WinUI) GUIプログラミング Part30
https://mevius.5ch.net/test/read.cgi/tech/1667010874/

関連スレ
Windows 10 UWPアプリ開発Part 3
https://mevius.5ch.net/test/read.cgi/tech/1627556967/

コードを貼る場合は以下のサイトの利用をお勧め。
https://ideone.com/

**デフォルトの名無しさん** · 2023/08/27(日) 09:09:39.66

お前の方こそブーメラン刺さってねｗ

**デフォルトの名無しさん** · 2023/08/27(日) 11:36:52.09

>>830
どんなの？

**デフォルトの名無しさん** · 2023/08/27(日) 12:46:27.21

>>832
そのとおりだよ。わざと >>825 を真似て醜悪な文面にしたのだから
>>831 のレスは ID:QKHGYPpz の鏡だよ

**デフォルトの名無しさん** · 2023/08/27(日) 12:58:47.33

そんなこともわからない>>832の頭の悪さときたら
ってことでしょ

**デフォルトの名無しさん** · 2023/08/27(日) 13:51:55.91

viewmodelsって対応するviewに表示するためのデータとロジックを持ってるって認識で合ってる？
コード見てると他のviewmodelファイルでインスタンス化されたりプロパティが呼び出されてたりしててあれこういうのありなの？って

**デフォルトの名無しさん** · 2023/08/27(日) 14:43:13.39

例えばどのファイルのどこがおかしい、改善すべきと言わないと

**デフォルトの名無しさん** · 2023/08/27(日) 21:19:33.66

機能修正の事前準備としてリファクタリングさせてください
とか言ってもひとまず機能修正優先でとか動いてるんだから余計なことするなとか言われるのがオチだよね

**デフォルトの名無しさん** · 2023/08/27(日) 21:40:22.11

もうその5chブラウザの事ほっとけよ
作者があまり顔出さないのに
作者不在のままここで毎回ゴタゴタが発生であほらしい

ほっとくのが吉

**デフォルトの名無しさん** · 2023/08/28(月) 19:25:42.52

心理的安全性の低いスレだな

**デフォルトの名無しさん** · 2023/08/28(月) 19:58:34.85

攻撃しても何もいいことはないのになあ…
googleの本でも読めば良いのに

**デフォルトの名無しさん** · 2023/08/28(月) 20:00:38.72

ふと思ったことや感じたことを言うと叩かれる　→　心理的安全性が低い
他人の行ったことを否定する　→　心理的安全性が低い

本人に自覚がないのが恐ろしい

**デフォルトの名無しさん** · 2023/08/28(月) 20:44:27.43

マスゴミって批判しないで、記者が萎縮してしまいます。でも自分達は批判も攻撃もするけどね。みたいな二重基準？

**デフォルトの名無しさん** · 2023/08/28(月) 21:29:09.23

技術的な話とかに関して色々批判はいいと思うけど
最後は人格攻撃と不毛な事になるのが多いからなw

**mdysdev** ◆XSDsAilQpD0E · 2023/08/30(水) 09:16:29.73

MVVMって例えばWPFでいうなら、VMでSystem.Windows名前空間をusingしないっていう認識で合ってる？
要はVMだけでOS非依存のdll化できるか

**デフォルトの名無しさん** · 2023/08/30(水) 10:42:16.63

そんな定義は聞いたことないな

**デフォルトの名無しさん** · 2023/08/30(水) 11:12:09.35

究極の疎結合って意味では合ってる
CommunityToolkit.mvvmもプラットフォーム非依存だし極端な話、上側がWinUI3でもVMそのまま動くってことでしょ

ただ実際問題すげーめんどくさいとは思うがｗ

**デフォルトの名無しさん** · 2023/08/30(水) 13:38:27.33

だね、5chブラウザのほうでViewModelでウィンドウクラス?を参照してたのは気になってた

まぁ、最初の1回だけは勉強のためMVVMガチガチにやって頑張ってもいいし
そこは本人次第

**mdysdev** ◆XSDsAilQpD0E · 2023/08/30(水) 14:56:17.68

ありがとう、System.Windowsを分離してみる。

>>848
確かにWindowは分かりやすく「ん？」ってなるけど、
ClipBoardとかBitmapImageとかもみんなSystem.Windows配下なんだよね。
これらの処理を全部持ってくと、Viewにも結構ロジックが必要になりそう。
UIフレームワーク固有の機能なんだから疑問を持つのがおかしいのかもだけど

**デフォルトの名無しさん** · 2023/08/30(水) 23:23:43.59

View固有の機能じゃなければ分離しなくてもよい

**デフォルトの名無しさん** · 2023/08/31(木) 00:04:15.85

その前にenumの機能のおさらいをしたほうが良い

**デフォルトの名無しさん** · 2023/08/31(木) 01:17:12.25

MVVMといえばうちの会社でのプロジェクトでさぁ例えばだけどmodelにcircleクラスがあるとするじゃん
んでそれをコンストラクタの引数に取るVmCircleなるクラスをわざわざ作るのよ。んでそれを各種viewmodel内部でいじるんだけど、VmCircleはCircleのviewmodelとか言ってるの
おかしいでしょそれはviewmodelでもなんでもないでしょって言ったんだけどいやviewmodelだって
これ俺がおかしいのか？

**デフォルトの名無しさん** · 2023/08/31(木) 01:44:14.25

>>852
サーバサイドでも使う Entity とかを .NET Standard で共有して、
クライアントサイドではそれをINotifyPropertyChanged を実装したクラス (VM) に変換する必要がある、
もしくは将来的に変更通知が必要になる可能性を見越してそうしておく、
とかならありえなくはないんじゃない？

**デフォルトの名無しさん** · 2023/08/31(木) 07:06:57.56

>>845
変な理解しているな。
ViewModelでBitmap加工などは普通にやる。　当然、System.Windowsをusingする。
Viewのエレメントに直接アクセスするなという事だけ。　いわゆる委譲だな。
例えば、Viewにパラメーター渡すために、IxxxViewRepositoryインターフェースをViewに継承させ、そのレポジトリをViewModelにインジェクションすればそれでOK。
ContainerのChildrenは、ViewModelにダイナミック生成バインドできないので、Add、Remove、Move操作をそういう方法でやる。
DDDなどのクリーンアーキにチャレンジしてみれば、その辺はインチュイティブに理解できるようになるよ。

**デフォルトの名無しさん** · 2023/08/31(木) 07:56:35.25

>>853
そもそもviewmodelってviewとmodelをつなぐ役割をするものじゃないんですかね
別に対応するviewなんて何も無いただデータとそのメソッドを持つだけのクラスをviewmodelと言えるんでしょうか

**デフォルトの名無しさん** · 2023/08/31(木) 11:36:17.81

https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-14

うんこ品質の時間です
突然1.4がリリースされやがった
9月末が予定じゃなかった?

**デフォルトの名無しさん** · 2023/08/31(木) 12:07:44.06

>>854
それ、すごい労力かかる割にはWPF専用のViewModelになっちゃうじゃない。
いまUIライブラリ移行の過渡期なんだし、再利用できるViewModelとか考えないの？

**デフォルトの名無しさん** · 2023/08/31(木) 12:40:08.29

>>855
俺の理解が間違ってるかもしれないけど、
その Circle クラス？が画面上の円のコントロールかなにかの DataContext になってるなら ViewModel であるといえるんじゃないだろか。
画面上のどこにもバインドしてないんなら違うと思うけど。

例えば ListBox の ItemsSource にバインドするコレクションの各要素の型は ViewModel と言えると思う。
ListBoxItem を 1つの View として見た時にその DataContext になるから。

↓これとか ItemViewModel というのを定義してる。
https://blog.okazuki.jp/entry/2016/04/08/233620
ItemViewModel

**デフォルトの名無しさん** · 2023/08/31(木) 13:22:03.44

viewmodelはmodel用のviewじゃなくてview用のmodel
各種viewmodelでcircleモデルのview用の変換やviewからの入力に対してモデルとの橋渡しをする場所としてvmcircleを作ってるんならまあ理解できる

**デフォルトの名無しさん** · 2023/08/31(木) 14:00:23.53

何なら納得するんだろうか？

画面に複数のタブページがあるアプリがあって
メインVMに複数のタブページ用のVMがリストなどで持たれている(直接のモデルじゃなくて)

これでおかしいと思うのかどうか

**デフォルトの名無しさん** · 2023/08/31(木) 15:36:13.08

XAML Islandsとか名前がよくない
絶海の孤島のイメージだ

**デフォルトの名無しさん** · 2023/08/31(木) 15:53:03.73

Islandsで孤島？

**デフォルトの名無しさん** · 2023/08/31(木) 16:07:40.97

複数形だから孤島ではないな

**デフォルトの名無しさん** · 2023/08/31(木) 16:52:36.04

>>857
VieModelの再利用？
再利用するのはViewの方であって、ViewがViewModelへのバイディング権がある。
それで、フレキシブルな画面構築ができる。
ロジックの再利用は、Domain層にまとめる。

**デフォルトの名無しさん** · 2023/08/31(木) 17:36:52.11

>>864
ん？例えばMAUIとかWASMに移植するときはViewModelを全部作り直すってこと？
大変じゃね？っていうかそれってMVVMじゃなくね？

MVVMって画面とロジックの分離であって、画面が変わるたびに作り直さなくちゃいけないなら
それはViewModelではなくViewの範疇では？

**デフォルトの名無しさん** · 2023/08/31(木) 18:44:34.81

ViewModelはviewとmodelの間が互いにデコボコしてて
綺麗にくっつかない場合に間に入るつめもの

もともときれいにくっつくなら不要

Viewが変わればまた形に添ったViewModelが必要になる

**デフォルトの名無しさん** · 2023/08/31(木) 19:17:40.59

クライアント側にあるView層にViewとViewModelがある
サーバー側にModel層があって自分の場合はREST full APIで作られたSaaS出ある場合が殆ど
業務ロジックはModel層内に全てあるので再利用可能

**デフォルトの名無しさん** · 2023/08/31(木) 19:22:25.33

View層にはWPFを動作させるための処理しかない

View層をReactで作ってもそこにあるのはReactを動作させるための処理しかない

業務ロジックは全てサーバー側にあって全く無駄にはならない

**デフォルトの名無しさん** · 2023/08/31(木) 21:51:01.50

>>762
今思いついたんだが「sugar dragonfly」はどう？

**デフォルトの名無しさん** · 2023/09/01(金) 16:45:19.11

機器の通信サンプルアプリをWPFで作るのは有り？
サンプルを参考にする相手がWPFを使ってるかわからないから、WinFormsの方が無難かな？
一番無難なCUI版は出来たからコアの通信部分は変わらなくて、通信結果を見やすくするだけなんだけども

**デフォルトの名無しさん** · 2023/09/01(金) 17:16:03.23

ActiveXでExcel VBA対応するのが無難だな

**デフォルトの名無しさん** · 2023/09/01(金) 19:47:27.67

>>866
それはVMじゃない。どっちかというとMVCのCに近い。

**デフォルトの名無しさん** · 2023/09/01(金) 21:56:19.74

>>866の説明はCよりVMよりだと思う
VMはModelを特定のView用に変換した状態を持っておくもの

MVC
Ｖーーーーーーーー　監視　ーーーーーーー＞Ｍ
Ｖーーー入力ーー＞　Ｃ　　ーーー入力ーー＞Ｍ
Ｖ＜ーーーーーーー　通知　ーーーーーーーーＭ

MVVM
Ｖーーー監視ーー＞　ＶＭ　ーーー監視ーー＞Ｍ
Ｖーーー入力ーー＞　ＶＭ　ーーー入力ーー＞Ｍ
Ｖ＜ーー通知ーーー　ＶＭ　＜ーー通知ーーーＭ

**デフォルトの名無しさん** · 2023/09/01(金) 22:06:47.51

みんなめちゃくちゃだな..

**デフォルトの名無しさん** · 2023/09/01(金) 22:16:55.21

>VMはModelを特定のView用に変換した状態を持っておくもの

なにその珍解釈

**デフォルトの名無しさん** · 2023/09/01(金) 22:33:11.78

一人だけ俺様理論がおるな

**デフォルトの名無しさん** · 2023/09/01(金) 22:55:04.64

みんなVIEWを差し替え差し替えでMODELを流用することやってるの？

**デフォルトの名無しさん** · 2023/09/01(金) 23:31:31.63

いや全然

**デフォルトの名無しさん** · 2023/09/02(土) 00:18:16.99

自己満ですなーー
WPFのMVVMがまさに究極の自己満

MVVMとかvue.jsとかangular、androidとかでも普通に使うし
そっちは実装コストもかからん

**デフォルトの名無しさん** · 2023/09/02(土) 05:21:08.01

android studioはwindows formのポトベタと同じ感覚なんだが？

**デフォルトの名無しさん** · 2023/09/02(土) 08:18:23.73

>>877
モニターアプリでは良くやるよ。
化学プラントの製品毎の画面やライン管理の製品毎の32~4096接点モニターとかね。
モニターと非常停止等の共通アクション画面なら流用する。
ただし、Viewのビハンイドコードトリミングは必要。
それらを再利用というには微妙だな。　VMはペアで消費するものと考えるのが普通。
再利用というのはロジックの再利用を言うのが一般的じゃね？

**デフォルトの名無しさん** · 2023/09/02(土) 09:33:36.47

結局VMに何らかの描画以外のロジックを書いてる人が多いんだろうなと
mvvm原理主義者じゃなければ別に好きなようにしたらいいんだが

WPFは結局どのように実装すべきなのかハッキリとしたパターンが確立されなかった
これが一番の問題だった

明確に役割分担してオブジェクトの生死を適切に管理してる人間がどれだけいるのか

**デフォルトの名無しさん** · 2023/09/02(土) 09:49:03.02

>>875
あってるぞ
MをVに表示させる為に必要な形に変えたものだ
例えばM(Web APIのResult)をVM(Vにバインディンク可能なデータ型)に変換してVと接続する

**デフォルトの名無しさん** · 2023/09/02(土) 10:06:25.37

状態と言う意味が通じていないので話をしても無駄

v vm mでそれぞれ状態は持ってる
普通はmの状態のことを話すんだけど双方の話がかみ合っていない

**デフォルトの名無しさん** · 2023/09/02(土) 10:12:13.25

本来はMと全層から利用されるビジネスロジックが主体なんだけど
vmでガッツリロジックなり制御なりのコード書いてる人が多い

そういう人から見るとvmは状態を持っていると言う主張になる

**デフォルトの名無しさん** · 2023/09/02(土) 10:21:43.71

>>882
だね。
ViewModelはインスタンスプールの場という認識が無いとそうなるね。
Bitmap加工にしても、ロジックは別の層に置くもの。
ロジックはDomain層、ドライバーはInfrastructure層でカキコしておけば再利用というスタイルの本筋が見えてくる。

**デフォルトの名無しさん** · 2023/09/02(土) 10:42:05.01

wikipediaだとこうだな。VMはVが表示すべき状態を保持するというのが普通の理解だと思う。

ViewModel
ViewModel（ビューモデル）はViewを描画するための状態の保持と、Viewから受け取った入力を適切な形に変換してModelに
伝達する役目を持つ。すなわちViewとModelの間の情報の伝達と、Viewのための状態保持のみを役割とする要素である。

**デフォルトの名無しさん** · 2023/09/02(土) 10:53:39.97

という事はバリデーションもvmじゃなくてmでやるの？

**デフォルトの名無しさん** · 2023/09/02(土) 11:59:17.23

>>887 の定義だとちょっと密に思えてしまうな

https://learn.microsoft.com/ja-jp/dotnet/architecture/maui/mvvm

大まかに言うと、ビューはビューモデルを "認識" し、
ビューモデルはモデルを "認識" しますが、
モデルはビューモデルを認識しておらず、
ビューモデルはビューを認識していません。
したがって、ビューモデルではビューをモデルから分離させ、
ビューとは独立してモデルを進化させることができます。

**デフォルトの名無しさん** · 2023/09/02(土) 12:40:51.82

君たち一旦モデルの事はわすれろよ
めちゃくちゃすぎる

**デフォルトの名無しさん** · 2023/09/02(土) 13:16:00.96

>>882の言うようにハッキリとしたものがないと同意した上で言わせてもらうが
>そういう人から見るとvmは状態を持っていると言う主張になる
VMは状態をもつ

めちゃくちゃすぎる
普通に状態を持つ

**デフォルトの名無しさん** · 2023/09/02(土) 13:18:09.94

アプリケーションの真の実態はMなんだから忘れることじゃないな
勘違いされがちだけどMはデータ置き場でもライブラリでもないアプリケーション本体

VMは表層でしかない
メッセージの仲介所
上で書かれたインスタンスプールでもない
仕事をするにあたりただどこかにあるモデルへの参照を持っているだけ

ModelAとModelBを参照して計算してModelCに入れるのはVMの仕事ではない
VMはMに単純なメッセージ飛ばすのが仕事

**デフォルトの名無しさん** · 2023/09/02(土) 13:35:29.82

ロジックを単にロジックと表現したりするとこみると
ロジックをビジネスロジックとプレゼンテーションロジックに分けて
考えてないよね

ここで>>882のじゃあ明確なその区別のルールは?って問題が出てくるが

**デフォルトの名無しさん** · 2023/09/02(土) 13:44:31.42

どうも自分の書き込み全体じゃなくて部分的な文章しか見てもらえてない気がする

>>884とかガン無視されてる

**デフォルトの名無しさん** · 2023/09/02(土) 13:46:57.02

あ、vmが状態を持つのはそのように書いたからであってあまり意味はない
適切なのかどうかは知らない

**デフォルトの名無しさん** · 2023/09/02(土) 14:04:49.20

でも>>892の見ると、君完全にFatModelの某riga◯◯氏の主張だよね

**デフォルトの名無しさん** · 2023/09/02(土) 14:09:38.75

>>896
誰それ？
VMは可能な限り薄くすべきだよ

**デフォルトの名無しさん** · 2023/09/02(土) 14:19:20.78

>VMは可能な限り薄くすべきだよ
いやいや、ViewModelは作る画面をモデル化したものだから
それは作る画面次第だから
VM薄くするために要件にまで介入する気なの?

(もちろん、VMに限らずスパッゲッティ排除したりすることはいいことだが)

**デフォルトの名無しさん** · 2023/09/02(土) 14:32:46.57

>>888
サーバー側でも結局必要になる処理なんで
バリデーション機能を提供するWebAPI定義してそっちでやってる
パフォーマンスもローカルでやるのと変わらん

自分設計の案件は
小計行の合計値など画面に表示されるものほぼ全てサーバー側での計算値だ

**デフォルトの名無しさん** · 2023/09/02(土) 14:40:30.69

>メッセージの仲介所
>デコボコしてて綺麗にくっつかない場合に間に入るつめも
これが先じゃないんだよ
例えば、学生を扱う時に「Student」クラス作ってNameとかAgeとか
状態持たせて「モデル化」するのと同じように

作る画面を同じように状態抜き出してロジック与えて名前を
付けたものがViewModel

こっちが先

**デフォルトの名無しさん** · 2023/09/02(土) 14:48:44.91

で、ViewModelの実装において画面が複雑なら、ビューモデルに書くプレゼンテーションロジック
が複雑になるし、Modelにドメインロジックの実行を依頼したりする

だから、
>メッセージの仲介所
とか表現が極端すぎる
ViewModelは画面をモデル化したもので、立派に独自のプレゼンテーションステート
やプレゼンテーションロジックも持つ立派な1つのエンティティです

**デフォルトの名無しさん** · 2023/09/02(土) 15:38:06.62

>>900
>作る画面を同じように状態抜き出してロジック与えて名前を
>付けたものがViewModel
作る画面(View)のもとになるのがModelなのでその過程をどの程度意識しているかどうか
言い換えればViewを所与のものとして受け取っているかどうかの違いでは？

それ以外の点はほぼ賛同できる

**デフォルトの名無しさん** · 2023/09/02(土) 16:13:13.84

>>902
>作る画面(View)のもとになるのがModelなのでその過程をどの程度意識しているかどうか

アプリケーションの実装はそう考える場合があるかもしれんがMVVMパターンとして
MとVMにそういう関係があることを求めてはいないと思うがな。

**デフォルトの名無しさん** · 2023/09/02(土) 16:37:06.13

>>903
いいこというね
>>890のモデルを忘れろってそういうことなんだわ
ViewModelはあくまでも作る画面をモデル化しておとしこんだのであって、
その作る画面がどのModelが元になってるか関係ないんだわ

**デフォルトの名無しさん** · 2023/09/02(土) 17:02:01.28

自分でロジックブーメラン投げて刺さってるし触れるだけ無駄なんだなと

ヒマつぶしにriga○○が何なのか調べてみたけどわからなかった
更に調べるとかなり前から懐かしのugayaのことをrigayaと言ってる人物がいる
多分この人なんだろう

rigayaと言うのは別人がいてNVEncの作者

**デフォルトの名無しさん** · 2023/09/02(土) 17:08:17.47

>>905
ごめんごめん
rigayaはNVEncの作者でugayaのほうか悪かった

**デフォルトの名無しさん** · 2023/09/02(土) 17:18:55.85

ロジックブーメラン

**デフォルトの名無しさん** · 2023/09/02(土) 17:35:30.95

何、しつこく
それも謝ってほしいのか?
すみませんでした

**デフォルトの名無しさん** · 2023/09/02(土) 17:45:52.02

なんの話をしているんだろうと思ったがこれか？
https://ugaya40.hateblo.jp/entry/model-mistake

**デフォルトの名無しさん** · 2023/09/02(土) 17:57:45.40

そうそれ
全部Modelに押し込めってことか?って事で
FatModelって勝手に呼んだけど

完全な正解はないから俺も含めてみんなおれおれMVVMを信じるだけw

**デフォルトの名無しさん** · 2023/09/02(土) 18:42:57.12

俺も>>909はVMの要件とは思わんな。
ただ、V→VM→Mというクリーンアーキテクチャで考えるならMからVMへの依存性逆転に使うインターフェースは
M側に含めることになるかな。それが「Modelの影」にあたるのかもしれんが。
言葉としては違和感があるな。どっちかというと「Viewの影」の方がしっくりくる。

**デフォルトの名無しさん** · 2023/09/02(土) 22:11:29.82

「Viewの影」か...

VMにはMからの応答データ以外にも
カレントフォーカスやら
リスト系入力コントロールのカレントインデックスやら
入力コントロールの変更前値なども保持してるね
これらはMではあまり取扱かわない

**デフォルトの名無しさん** · 2023/09/03(日) 18:43:28.44

>>911
Mにインジェクションはまずくね？
そもそも、EntityやModelは定義とロジックが入るクラスで、かつ、Domainに属するクラス。
ViewとViewModelはApplicationレイヤー。
Domainとは、外部参照ができない領域で、そこにPropertyインジェクションはリスクを覚悟した使い方。
何事もトリッキーが必要になる事はあるが、SOLID原則は可能な限り守るべき。

**デフォルトの名無しさん** · 2023/09/03(日) 18:47:29.66

この5chブラウザって実行できねぇじゃねぇかよ
とりあえずWindows 11 ProのSandbox環境立ち上げて
実行してもSeach app in the store?だっけ?
とダイアログが出て実行できねぇ
.NET 7のランタイムとかいれてもだめやわ
だるっ

**デフォルトの名無しさん** · 2023/09/03(日) 19:07:48.99

>>93
>Mにインジェクションはまずくね？

どこからそんな解釈が？

**デフォルトの名無しさん** · 2023/09/03(日) 20:37:38.19

本来のMVVMだとVMがMに命令を出してその結果をVMのプロパティーに反映だが
コレクションはMに無いとどうにもならないし、それをVMがリダイレクトする
この時点で初期のVMMVは破綻しているよな

**デフォルトの名無しさん** · 2023/09/03(日) 21:08:54.26

デザイナーとプログラマーと別けてやるならそうだか、自分一人でやるんならマイルールで頑張れば良い。他人は他人、気にせずに行こう！

**デフォルトの名無しさん** · 2023/09/03(日) 21:16:42.81

>>916
>本来のMVVMだとVMがMに命令を出してその結果をVMのプロパティーに反映だが

本来のMVVMと言うが、MとVMのやり取りにおける役割分担ってそんなに明確に定まったものはないと思うが。

**デフォルトの名無しさん** · 2023/09/03(日) 22:05:14.34

【クライアント側】
View (WPF)
ViewModel(WPF)
Model(c#, 業務ロジック以外のロジック、例えばUI処理に必要なロジックなど)
【サーバー側】
Model(c#, 業務ロジック)

みたいに実際はクライアント側にもModelが必要になる事が多い

**デフォルトの名無しさん** · 2023/09/03(日) 22:46:24.33

>>918
創世記の頃はさっき書いたようなのだったが、ビジネスロジックをほぼ全てMに書く派閥ができてカオスになった
あと、ReactivePropertyでMから簡単にリダイレクト出来るようになったのも大きい

**デフォルトの名無しさん** · 2023/09/03(日) 23:12:27.45

今時はPropertyChanged.FodyやObservablePropertyで自動化
便利になりました

**デフォルトの名無しさん** · 2023/09/03(日) 23:49:15.10

クライアント側やクライアント側にもModelが存在しえるが
ここにはUI要素が殆どなく(あったとしても抽象化されている)
WPF以外からも再利用が可能だ

ViewModelは特定のView専用に実装されており
異なる種類のViewの実装から再利用する事は望めないのが普通だ

**デフォルトの名無しさん** · 2023/09/03(日) 23:50:04.10

訂正）サーバー側やクライアント側にもModelが存在しえるが

**デフォルトの名無しさん** · 2023/09/04(月) 01:14:09.52

VewModelはViewの構成要素(データやコマンド)には依存するけど実装には依存しないでしょ

**デフォルトの名無しさん** · 2023/09/04(月) 19:44:13.60

昔SilverLightと言うのがありまして…

**デフォルトの名無しさん** · 2023/09/04(月) 19:56:38.46

光ちゃん好き

**デフォルトの名無しさん** · 2023/09/04(月) 20:00:29.56

M、VMはそのままで、VをWPFでもUWPでもUnoでもMAUIでもコマンドプロンプトでもまだ存在しないビューにしても成り立つのが理想のMVVM

まあ本体のバージョンやらなんやらで制約受けるんだけども

**デフォルトの名無しさん** · 2023/09/04(月) 22:51:14.61

>>927
機種やOS依存しないのはMだけで、VMはWPFからWinUI3に変わるだけでも作り直し
Win32とWinRTは名前空間が別だ

**デフォルトの名無しさん** · 2023/09/04(月) 23:30:01.70

前からいるVMは作り直さなくてもいいと言う人は実際に使ってない気がするんだな

**デフォルトの名無しさん** · 2023/09/05(火) 05:52:19.52

Vが変わったらVMも作り直しとかそもそもお前のはMVVMじゃないぞ

**デフォルトの名無しさん** · 2023/09/05(火) 20:28:59.35

MVVMでは、Modelはただの定義であって、それがどこにあろうが、ローカルインスタンスはViewModelにある。
ModelインスタンスはViewにバイディングされるが、Model管理はサブスティチューターやインタラクター等の中間介在者経由で行う。
Modelにインジェクションは、中にパーサーを持たせ、ファイヤーや他にアソシエートさせるという事だろうが、それは、再利用性を損ねる事になる。
MVVMは見かけはMVVMだが、実際には、疎結合実現のために、取り巻くサービスから構成される。