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/07(水) 19:54:05.96

>>376みたいな人間がUXを語るべきじゃないな
感性も腐ってそう

**デフォルトの名無しさん** · 2021/07/07(水) 20:56:03.54

開発者のエゴイズム丸出しでいかにもWPF好きらしくていいじゃん

**デフォルトの名無しさん** · 2021/07/07(水) 21:01:06.97

WPFって見た目がカラフルでもUIデザインの基本的なプロトコルはクラシックなWinアプリのままなんで、
画面遷移とか作り込んで完全にWebやスマホ風にしてしまうのでもない限りは即時反映はかえって混乱を招くと思う

**デフォルトの名無しさん** · 2021/07/07(水) 21:03:20.07

彼はむしろWPFアンチだよ
冗長くんだもん

**デフォルトの名無しさん** · 2021/07/07(水) 22:28:03.79

>>388
バインディングの都合を満たすのはVMの仕事で、Mの独立を保つ為に犠牲になる係でしょ？

**デフォルトの名無しさん** · 2021/07/07(水) 23:12:07.60

しかし、Modelの一部をINotifyPropertyChangedやReactivePropertyに変えるなど
規模にもよるが小一時間の仕事だろうに

使いたくない理由を無理やり探しているんだろうね

**デフォルトの名無しさん** · 2021/07/07(水) 23:14:24.01

INotifyPropertyChangedなんてWinFormでも使うだろうに
何のためのモデルクラスだったんだろう

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

>>394
手間の問題じゃなくて
なんでUIフレームワークの都合でモデルをいじらなきゃならんのかって話

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

WPF使う場合はやはりモデルから対応しなければならない
それが嫌なので躊躇してしまう

モデルが依存関係を除去したところでINotifyPropertyChanged実装しないといけない

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

>>394
なんで
INotifyPropertyChanged
ReactivePropert
みたいのがmodelにあんの？(;´д｀)

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

MVVMで作ればINotifyPropertyChanged実装しなきゃいけないのはUIとバインドするViewModelだけだぞ
ModelをObservableにしたければ、独自のObservableインターフェース使えたければ使えばいいじゃん
Modelは無理にINotifyPropertyChanged使う必要はない

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

つか、要件としてModelをObservableにするならUIフレームワーク関係なく
何かしらのObservableインターフェースが必要になってくるんだが

他のフレームワーク、言語使っても同じなんだが頭大丈夫??

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

そのへんフィールドをプロパティにするだけで全部やってくれてたらもっとユーザー増えただろうな

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

INotifyPropertyChangedの実装がWPF特有の問題だと思ってるあたりが頭おかし

他のUIフレームワークでもモデルの変更に応じてUI変えるなら、Observeする仕組みが必要でINotifyPropertyChangedに相当する機能をどのみち実装しなきゃいけないのに

>>396,397
君は他のUIフレームワーク使ったときにどうやって実装するわけ??

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

>>402
明示的なコード書かなくても
フレームワーク側でバインド解決できるのが
普通のMVVM

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

そういうフレームワークの具体例を1個上げて

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

>>402
WPFみたいなバインディングはしません

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

>>405
WPFみたいなバインディングしなくてもモデルをObservableにするならどの道何らかのインターフェースが必要になるって話をしてるんですけど理解してますでしょうか??

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

>>398
通知のためだけのインターフェースがボコボコ増えてくのが嫌だからさ
全てRxのIObservableならよかったな
つかWPFもバインディングエンジンの部分をプラガブルにしろよな
なんでINotifyPropertyChangedみたいなクソにしがみついてるのか理解しかねるね

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

てか今後新しい通知インターフェースを宣言した奴は死刑でいいよ
殺す

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

趣味でやってるだけだからよくわからんけど同じプロパティー２回書かせるのやめてくれ
めんどくさい

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

>>407
メリットは外だしなんで
カスタマイズして
オレオレ仕様に出来る以外ない

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

.net mauiのMVUってINotifyPropertyChangedの仕組み乗っかるの??
ブログの例ではState<T>とかあるけど
State<T>ならjetpack composeと同じやん

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

>>406
だからバインディングはVVMまででいいって言ってんじゃん

**デフォルトの名無しさん** · 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に変更通知があるのが普通と思ってのはお前