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

**デフォルトの名無しさん** · 2021/06/20(日) 17:04:18.66

Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part25
https://mevius.5ch.net/test/read.cgi/tech/1612522463

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

**デフォルトの名無しさん** · 2021/07/08(木) 13:54:52.32

これでいいじゃん。using追加してAnnotation付けるだけだよ
https://www.reactiveui.net/docs/handbook/view-models/boilerplate-code

[Reactive]
public string Name { get; set; }

**デフォルトの名無しさん** · 2021/07/08(木) 13:55:12.53

まあ他の言語のFWはばかでも書けるけど、
ことWPF含めMS主導のは一部の細かい主張に答えるためか、
やることが回りくどいんだよな
FW使ってるのに書くことが多いと言うか

**デフォルトの名無しさん** · 2021/07/08(木) 14:00:41.26

>>412
じゃあ、モデルでは好きなObservableインターフェース使えばいいじゃん
独自でもRxでもご自由に

**デフォルトの名無しさん** · 2021/07/08(木) 14:05:52.94

>>415
うわ頭悪そう

**デフォルトの名無しさん** · 2021/07/08(木) 14:35:39.28

>>404
case: knockout.js

**デフォルトの名無しさん** · 2021/07/08(木) 14:48:13.57

>>417
それ全然違うから...

**デフォルトの名無しさん** · 2021/07/08(木) 14:51:52.72

>>404
case: React

viewModel.value1

**デフォルトの名無しさん** · 2021/07/08(木) 14:57:32.77

>>419
>>417と同じのりで挙げてるならこれも違う

**デフォルトの名無しさん** · 2021/07/08(木) 16:00:11.32

>>420
おお、すまん
訂正

>>404
case: React

{viewModel.value1}

**デフォルトの名無しさん** · 2021/07/08(木) 18:03:12.85

>>404
case: Vue.js

{{viewModel.value1}}

**デフォルトの名無しさん** · 2021/07/08(木) 18:32:35.94

h5za3xa1は世間知らずのWPF至上主義者なんだ

許してやれとは言わないが冷たい目で見ればいいよ

**デフォルトの名無しさん** · 2021/07/08(木) 18:33:09.06

>>404
case: Blazor

@viewModel.value1

**デフォルトの名無しさん** · 2021/07/08(木) 18:35:59.60

ここからまたプロパティで書くべきかどうかみたいな話になるのだろうか

recordの仕様と実装が中途半端だから解決法にならない

**デフォルトの名無しさん** · 2021/07/08(木) 18:45:37.60

>>404
実はWPFでもstaticだけはObservableの実装無しでいけたりします。
なのでModelの直バインドも可能です。
更新はコントロールを強制再描画すれば良い。

case: WPF(static only)

<TextBox Text={x:static viewModel.value1}/>

**デフォルトの名無しさん** · 2021/07/08(木) 19:30:36.43

なんでView-ViewModelのバインディングの事例を並べてるの?
Modelの話じゃなかったっけ

**デフォルトの名無しさん** · 2021/07/08(木) 19:48:49.81

person.Nameみたいなのにバインディングされていて
Name変更時に通知する仕組みはモデルの責任じゃないけどそれが必要になる

他のフレームワークのように別の仕組みが通知するのが普通
WPFは普通じゃないし劣っている

**デフォルトの名無しさん** · 2021/07/08(木) 20:03:20.69

だから、「WPFも同じことできてWPFも当てはまる」から
>>417,>>419全部間違っているっていってんのに
何いってのお前？アホ？？
ちなみにWPFの場合は
<TextBox Text={Binding Path=viewModel.value1}/>

**デフォルトの名無しさん** · 2021/07/08(木) 20:04:13.12

>>426宛ね

**デフォルトの名無しさん** · 2021/07/08(木) 20:26:48.87

引っ込みつかなくなって可哀想

**デフォルトの名無しさん** · 2021/07/08(木) 20:35:30.05

>>428
その通り

>>402をうけての>>403だから、
「変更時に通知をする仕組みを一切実装する必要なくフレームワーク側で全部かってにやってくれる
」ようなこと>>403が言い出すからそういうフレームワークがあるならあげろっていってんのに

なんでどれも変更時に通知する仕組みを実装する必要あるフレームワークあげてんだよ

変更通知しないなら、WPFだって>>429で書いたようにINPC実装する必要ないしそんなフレームワーク
を挙げろっていってない

**デフォルトの名無しさん** · 2021/07/08(木) 20:42:51.18

person.Name見たいのはいつ変更したかなどはわかりやすいが
普通のクラスなどはいつどこで更新したのかが非常に追いにくい

目視でバグが確認できたとしてそれがどこで変更されてるのかがわかりにくい
バグがつぶしにくい

**デフォルトの名無しさん** · 2021/07/08(木) 20:51:56.44

とりあえず、

読解力ないバカが多すぎってのだけはわかった

**デフォルトの名無しさん** · 2021/07/08(木) 21:02:34.08

やったじゃん
俺以外みんなバカ宣言して精神的勝利だ

**デフォルトの名無しさん** · 2021/07/08(木) 21:07:38.15

まぁ「俺の言いたいことを理解してくれない奴」は多いよな、いつでも。

**デフォルトの名無しさん** · 2021/07/08(木) 21:17:18.89

真の天才は死んでから評価されるのさ

**デフォルトの名無しさん** · 2021/07/08(木) 22:41:40.59

Mに変更通知機能無いって大変そうだな

**デフォルトの名無しさん** · 2021/07/08(木) 23:02:26.20

>>変更時に通知する仕組み

MVVMだから変更を監視する巧妙な仕組みがあって
（フレームワークによって思想が違う）
その仕様にのっとって適時勝手にバインドが動作する
のでコードは増えない

**デフォルトの名無しさん** · 2021/07/08(木) 23:53:25.76

MをPOCOで作りたがる人いるよね。通知を実装するのも嫌がる。

**デフォルトの名無しさん** · 2021/07/09(金) 00:11:25.67

個人的には
(client: view, view-model)~network~(service: model)
としてる
入力バリデーションもmodelのみだ
へんかな？

**デフォルトの名無しさん** · 2021/07/09(金) 00:39:31.73

>>440
それは世界の常識
WPFのMがおかしい

**デフォルトの名無しさん** · 2021/07/09(金) 07:02:13.37

>>442
いや、WPFのMもPOCOで作るのが常識。

**デフォルトの名無しさん** · 2021/07/09(金) 16:02:03.33

朕はPOCOなり

**デフォルトの名無しさん** · 2021/07/10(土) 01:49:25.85

ふーん
POCOでModel変更感知するのって面倒じゃない？

**デフォルトの名無しさん** · 2021/07/10(土) 01:58:32.76

POCOってなーに？

**デフォルトの名無しさん** · 2021/07/10(土) 06:16:51.11

Modelで変更通知なんかしない。
VMとMの区分けすらできないならMVVMで作らなきゃいいのに。

**デフォルトの名無しさん** · 2021/07/10(土) 09:14:28.45

田舎者がなんか言ってるぞ

**デフォルトの名無しさん** · 2021/07/10(土) 09:27:48.37

>>447
Modelの変更はどうやってViewModelやViewに反映されるの?

**デフォルトの名無しさん** · 2021/07/10(土) 09:43:48.41

PODのようなものと混同してんのかな。
POxOから外部に何らかの通知をするのは別に普通だろ。依存の方向とか強くなりすぎるなとか一般的な注意をするだけ。

**デフォルトの名無しさん** · 2021/07/10(土) 10:05:00.92

>>449
Reduxならプロパティ変更イベントは必要ないよ

**デフォルトの名無しさん** · 2021/07/10(土) 10:17:17.62

>>451
例じゃなくて仕組みを知りたい
VM側からポーリングでもしてるの

**デフォルトの名無しさん** · 2021/07/10(土) 10:21:20.73

M自身が能動的に処理を行うことは無い。
Mに対してはVMから変更かける。通信やDB操作は外部プログラム（dll等）の役目だし、
ちょっと規模が大きいアプリなら外部通信などの処理は別プロジェクト（dll）にまとめられてるはずだろ？
外部プログラムが何らかの処理してMを変更し、外部プログラムの処理結果はVMでイベントハンドリングして
UIを更新する

**デフォルトの名無しさん** · 2021/07/10(土) 10:29:02.22

VとVMで1つのプロジェクト（UI担当）
Mと通信処理などをまとめて1つのプロジェクト（System.Windowsを参照しなければ汎用ライブラリ）として
.net core等でも使用可能）
もちろんVMからSQL文を発行することもある

日曜大工レベルのアプリならVMの中で通信処理などビジネスロジックを全て含める

**デフォルトの名無しさん** · 2021/07/10(土) 10:37:32.94

>>452
更新されたMが自発的にイベントを発火するか、VからMを更新するアクションが発生する毎に更新後のMの値を取りに行くかの違い。
flux/reduxのような一方向データフローでモデル更新がシリアライズされているから実用になること。

**デフォルトの名無しさん** · 2021/07/10(土) 10:54:10.61

V以外からMが更新される場合は、Mを更新した処理とVMが強く結合されるってことね

**デフォルトの名無しさん** · 2021/07/10(土) 10:56:13.18

Mの発火をVMが受け取りまた発火、Vが描画とか手間かかるしチームで案件やってると教育コストもかかる。
技術に疎いマネージャーだとクリックイベントに全部書けやとか言ってくるんだよね。

**デフォルトの名無しさん** · 2021/07/10(土) 11:07:48.66

>>456
flux/reduxについて言えばアクション自体への結合は不要。
基本的にMは全部単一のストアにまとめられていて、どこかが更新されるアクションが発生したら全員でMの更新を見に行くような感じ。

**デフォルトの名無しさん** · 2021/07/10(土) 11:09:30.03

>>456
モデルにぶら下がってるVMはフレームワークが把握しているから、フレームワークにMの更新メッセージを投げるだけだよ

**デフォルトの名無しさん** · 2021/07/10(土) 11:13:06.20

なおMのどのプロパティが更新されるかの特定も不要で、VMはあくまでMの現在の状態に対する関数として更新後のV全体を出力するだけでいい
あとはフレームワークがよしなに差分を取って変更を反映してくれる

**デフォルトの名無しさん** · 2021/07/10(土) 11:14:26.03

Mへの更新は全部フレームワーク経由で実施するってことか
フレームワーク君頑張るなｗ

**デフォルトの名無しさん** · 2021/07/10(土) 11:17:08.14

>>461
更新されたMをフレームワークに通知するだけだ
フレームワークの責務はメッセージのルーティングに過ぎなくて、Mがフレームワークの配下にいなきゃいけない訳じゃないよ

**デフォルトの名無しさん** · 2021/07/10(土) 11:26:26.12

ちなみに>>453,454はただのMVVMだよね??

**デフォルトの名無しさん** · 2021/07/10(土) 11:28:40.75

V以外でのMの更新自体はM寄りの処理だよね
Mの各プロパティから個別に更新通知が行くか、代表して更新通知が行くかの違いであって
Modelからの変更通知が無いってのはちょっと違うな

**デフォルトの名無しさん** · 2021/07/10(土) 11:35:14.88

>>464
ルーティングの責務をM自体ではなくその外で持つことで、M自体を汚さなくて済むようになった
メタ情報を外出しするという点ではEFのPOCOなんかも似たような仕組みだな

**デフォルトの名無しさん** · 2021/07/10(土) 11:43:48.27

>>462
フレームワークはMが更新されたことをどうやって知るの？

**デフォルトの名無しさん** · 2021/07/10(土) 12:19:02.06

>>466
ああ、わかったただのMVVMの変種か
今までだって、MVVMで作ってた時はModelでimmutableなのをあったけど、
イメージとしてModelを全部immutableにして、ViewModelのほうに全部押し込めって話か

極端な話Modelを全部immutableにして、後のつじつまあわせは全部ViewModel(Store)で全部やれってことww

負荷が全部ViewModel(Store)にいくってことじゃね??

**デフォルトの名無しさん** · 2021/07/10(土) 12:32:05.86

今までだって例えばMVVMでTwitterアプリを作るとき
まず、汎用的なTwitterAPIを叩いてPOCOを返すだけのライブラリを作って(A)

(A)を内部で使ったModelを作る
必要ならここでINPCの変更通知を実装(B)

で、後はViewModelをつくるだけど、

(B)をすっとばして、ViewModelで(A)を使ってここですべてやる

こんな感じ??

**デフォルトの名無しさん** · 2021/07/10(土) 12:35:43.17

だからそもそも今までだってどこのModelか知らんが(A)の部分は汚染されてないけどな..
二つ似たようなの作ってるが..

**デフォルトの名無しさん** · 2021/07/10(土) 12:52:18.73

もちろん、Modelをmutableにしてもいいけど、ViewModel(Store)内でModelを直接更新するからModelの変更通知機能は全く必要なくて、更新後ViewModel(Store)がViewに状態が変わりましたよって通知できればいい

やっと理解できました
ありがとう

**デフォルトの名無しさん** · 2021/07/10(土) 15:15:27.78

mvcやらmvvmやらに全てあてはめようとして考えて、
訳わかんない考えに染ってるのばっかだな

**デフォルトの名無しさん** · 2021/07/10(土) 15:53:06.08

まあデザインパターン病と同じ。

**デフォルトの名無しさん** · 2021/07/10(土) 16:12:10.43

>>470
これが何も知らない新人君でもやる普通の実装なんだがな

**デフォルトの名無しさん** · 2021/07/10(土) 18:17:59.49

>>470
そうすると複数のビューで一つのモデルを参照しているようなときは
ひとつのVMだか何だかが複数のビューと対話するん？

**デフォルトの名無しさん** · 2021/07/10(土) 18:34:12.08

というかこれって答えあるのか？

**デフォルトの名無しさん** · 2021/07/10(土) 18:37:01.39

オブザーバーでも
イベントでも
好きなパターンで実装すればよろし

**デフォルトの名無しさん** · 2021/07/10(土) 18:52:36.88

>>470
それは間違いだよｗ

VMにM更新のロジックを書くなよとｗ
VMごとにロジック書いて不整合があってバグ発生するだけ

**デフォルトの名無しさん** · 2021/07/10(土) 18:54:15.71

VMからMにはメッセージのみ送る

馬鹿はVMからMをいじる

**デフォルトの名無しさん** · 2021/07/10(土) 18:57:20.02

WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
これがモデル汚染

最近はビジネスロジック層を作ってお茶を濁してるけどそれも結局通知はどこなのか普通に迷うところ

**デフォルトの名無しさん** · 2021/07/10(土) 19:16:41.13

>>479
>WPFで本気でMVVMやりたいならMに通知もみんな書くんだよ
MVVMの話でいいならそれはrigaya?が勝手に言ってるだけだぞ
別に正解の定義なんてないだろうしどっちが正解とは言
言わんが

Modelのメソッドは結果を返さず、メソッドの呼び出しの結果、自身の状態(プロパティ)を変更するだけってやつだろ

**デフォルトの名無しさん** · 2021/07/10(土) 19:28:32.13

フレームワークの方法論は
その開発者が一方的に押し付けてる理屈なのに
気づけない馬鹿

**デフォルトの名無しさん** · 2021/07/10(土) 19:35:48.59

違うよ
知性の問題だ
それが理解できない馬鹿がバグを量産する

**デフォルトの名無しさん** · 2021/07/10(土) 19:36:54.45

馬鹿が自分が馬鹿でないと思って偉そうに何年もクソコードを書いてMVVM最高と言ってるだけだ

**デフォルトの名無しさん** · 2021/07/10(土) 19:38:06.79

うん、rigayaは開発者じゃないしね

**デフォルトの名無しさん** · 2021/07/10(土) 19:40:04.65

>>484
うがやじゃなくてお前ともう一人が馬鹿なんだ

やっと理解できましたじゃねーよ

**デフォルトの名無しさん** · 2021/07/10(土) 19:43:32.20

modelとviewModelの責務分けは
馬鹿には出来んよなーー

**デフォルトの名無しさん** · 2021/07/10(土) 19:47:15.76

外人でrigayaと同じ主張してる人見たことない
Modelで通知をするのが普通とか言ってるのはお前が勝手に思ってるだけ

>>481でMVVMを本当に作った人が特定できるならまずそれを特定してくれ。で、Modelで変更通知を実装するのが普通ってどこに書いてあるか教えてくれ

**デフォルトの名無しさん** · 2021/07/10(土) 19:52:15.95

もちろん、ViewModelはビューの状態を保持し、Modelに対してはModelのメソッドを呼んで
ビューに関するロジックを書くだけだぞ

Modelに変更通知機能あるかないかは全く関係ない話

勝手にModelに変更通知があるのが普通と思ってのはお前

**デフォルトの名無しさん** · 2021/07/10(土) 19:52:27.91

フレームワークつかうと
やっぱ宗教じみた変なのが誕生するなーー

まずはプリミティブなライブラリのみ使用して
デザインパターンとか理解してみる事をおすすめする

**デフォルトの名無しさん** · 2021/07/10(土) 20:01:26.66

>>478
「メッセージのみ送る」と「いじる」の違いはこいつの頭の中にしか無いんだろうな。

**デフォルトの名無しさん** · 2021/07/10(土) 20:06:44.05

MVVMでViewModelの責務は>>488なだけ

Modelが変更通知を実装するしないかは関係ない

MVVM黎明期、rigaなんとだけが日本で声上げたからあいつの馬鹿信者が増えたんだろう
しかも日本だけ笑い

**デフォルトの名無しさん** · 2021/07/10(土) 20:17:00.58

だから>>362で最初からバインディングはVVMまででいいって言ってるじゃん
何をそんな喧嘩腰で議論する必要があるのか

**デフォルトの名無しさん** · 2021/07/10(土) 20:23:04.54

“model” と “view、viewModel” の開発者は
分けた方がいいかもな

modelだけで業務が回せるようになってればいいだろ
実際modelはpythonで実装するの増えて
担当者も異なる事が多いわ

**デフォルトの名無しさん** · 2021/07/10(土) 20:43:24.78

>>492
バインディングの話じゃないって分かってない？

**デフォルトの名無しさん** · 2021/07/10(土) 20:55:14.46

>>494
え？変更通知なんだから要はバインディングの話でしょ？

**デフォルトの名無しさん** · 2021/07/10(土) 21:06:48.12

今日だけで50レスも進んでるのか
ヒマすぎだな

**デフォルトの名無しさん** · 2021/07/10(土) 21:45:12.95

例えば、ModelがImuutableでINPCを実装しないとするよ。で、Modelの更新はModelのメソッドを呼んで、
メソッドの戻り値として新しいインスタンスを返すとする
class Model {　// ImmutableなINPCを実装しない
　public Task<Model> UpdateAsync() <-　新しいインスタンスを返す
}

で、ViewModelから更新かけるとき、更新後、最新の情報に更新する必要あるなら、それは
あくまで表示の都合だから、ViewModelにそのロジックを書いて問題ないだろ？？

class ViewModel {
　public void Hoge() {
　　var result = await model.updateAsync()
　　// resultの結果を元にViewModel更新
　}
}

ModelがINPCを実装するかなんて本来はMVVMには関係なく俺にはこれも立派なMVVMにしか見えねぇわww

**デフォルトの名無しさん** · 2021/07/10(土) 21:59:07.18

もちろん、MVVMの厳格な定義なんて知らないし、極論すれば言葉の問題になるから
どっちが正解なんて言うつもりはないが、

rigaなんとか的に
「ModelはINPCを実装して、Modelのメソッドは戻り値は返さないで、
メソッドの呼び出しの結果自身の状態を変更し、INPC経由でViewModelに通知する」
で

おまえらこれだけがMVVMだと思ってるだけじゃんw

**デフォルトの名無しさん** · 2021/07/10(土) 22:07:37.44

>>497
うん、これが王道の作り方

**デフォルトの名無しさん** · 2021/07/10(土) 22:14:04.55

悪いけど売られた喧嘩で言わしてもらうが
>>485,486,490

はバカ三兄弟だわww

**デフォルトの名無しさん** · 2021/07/10(土) 22:54:51.35

ID:uwFcR1va
この人のサーバーサイドには
何が実装されてるのだろうか...

**デフォルトの名無しさん** · 2021/07/10(土) 22:55:10.24

>>500
なりほど、お前さん>>478の言う「メッセージのみ送る」と「いじる」の違いが理解できるならちょっと説明してみてくれないか。

**デフォルトの名無しさん** · 2021/07/10(土) 23:07:03.07

>>502
あ、ごめんひょっとして間違ってたら謝るわ

>>490って俺に対するあてつけ？じゃなかった？？
ただの>>478へのレスなら謝るわ。すみませんでした。

つか、あとrigaじゃなくてググるとugaだったw

**デフォルトの名無しさん** · 2021/07/10(土) 23:59:12.78

awaitはasyncが必要だろう。

**デフォルトの名無しさん** · 2021/07/11(日) 00:15:04.56

読みづらいからよ
続けるなら名前欄にスタンスを書いてくれないか

**デフォルトの名無しさん** · 2021/07/11(日) 01:46:58.32

やっぱりWPFはめんどくさいなw

**デフォルトの名無しさん** · 2021/07/11(日) 02:11:56.24

>>495
そこまで話を広げるとMに通知機能があろうが無かろうが全部バインディングだろうよ
今問題になってんのはVはVMに依存してる前提で
VMとMの問題だと思うんだが違うんかな

**デフォルトの名無しさん** · 2021/07/11(日) 02:13:20.15

>>506
WPFはめんどくさいっていうのが他の後発フレームワークとの比較なら分かるけど
WinFormと比較するんだったら比べものにならないくらい簡単だぞ

**デフォルトの名無しさん** · 2021/07/11(日) 02:52:00.72

>>508
ほんまかいな

**デフォルトの名無しさん** · 2021/07/11(日) 02:59:38.37

楽⇔面倒
簡単⇔難しい
単純⇔複雑
区別できない奴多すぎでは

**デフォルトの名無しさん** · 2021/07/11(日) 08:40:13.02

>>501
予想
ID:uwFcR1va 氏の構成

(client)
View
ViewModel
Model
Database Client Library

↑↓

(server)
Database Server

**デフォルトの名無しさん** · 2021/07/11(日) 12:56:04.27

一人ホームラン級の馬鹿がずっとレスしてるだけだな

MVVMでMから変更通知出すのは当たり前
VMでモデル変更して通知と言うけどモデル内で変更が生じた場合VMが変更通知出してるのかｗ？

VMは画面ごとに作るけどMに対応した処理はどこに書かれるんだ
まさか画面ごとか？