ふらっと C#,C♯,C＃（初心者用） Part149

2020/12/16(水) 11:29:35.35

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part148
https://mevius.5ch.net/test/read.cgi/tech/1590578921/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/01/23(土) 22:17:01.87

>>254
いや、あるでしょ
例えば、CLRプロパティと依存関係プロパティはどう？

それと、

>〇〇は方法1でもできるし方法2でもできる、△△は方法3と方法4でできる
>って言うのがまずいって思ってる

それって、
△△は方法1と方法2じゃ出来ないんだよな？
〇〇は方法3と方法4じゃ出来ないんだよな？
俺はそれがまずいと思ってる

〇〇が方法1でも方法2でも最終的に可能になるなら別に構わないんじゃないか？何が問題？
逆に、〇〇を解決しようと思って方法3で始めたが、後々になって方法1か方法2でしか出来ないことが判明した方が痛い

2021/01/23(土) 22:27:19.36

asp.netでデスクトップソフト開発ってどうなんだろうか

2021/01/23(土) 22:37:04.28

>>260
開始日と終了日の最大期間が3ヶ月で
開始日のデフォルト値が2000年のときの2021年1月23日～2月10日の設定方法に付いて悩みたいのか？

2021/01/23(土) 23:15:35.62

WinUI3というかUWPではバインディングが改良されて
コンパイル時に厳密な方チェックやってくれてバグに悩まずに済む

2021/01/23(土) 23:30:17.78

>>261
> 〇〇が方法1でも方法2でも最終的に可能になるなら別に構わないんじゃないか？何が問題？
うん、問題ないと思うならそれはそれでいいと思うよ

>>263
何を言いたいのかさっぱりわからんけど、個別の不具合の話じゃないなら説明してみて

2021/01/23(土) 23:31:10.83

>>264
そう言うのもWPFに還元して欲しいね

2021/01/24(日) 00:29:30.39

>>265
あったまわりぃなお前
データバインディングしてる変数に間違ったデータが入るようにしちゃって大丈夫か？

開始日と終了日に2000年1月1日が入ってるときに
開始日に2021年を入力したとき最大期間に反応してエラー出すだろ？
ここでエラーを出さなかったらバインドしてるGUIがおかしくなる
したらどうやって開始日と終了日に2021年を設定するんだよ

2021/01/24(日) 02:30:17.53

>>267
InotifyDataErrorInfoなどを使う場合、実装方法にもよるけど、間違った値や無効な値を保持する設計もおかしくないと思う。保持はするがエラーが発生しているという状態で、そのエラー内容を素直にViewが表示する設計。
逆にViewModelには正しい値しか保持しないとした場合、一時的にViewとViewModelで不整合が生じている状態になりますが、皆さんどのようにされてますか？

2021/01/24(日) 08:01:29.17

>>268
それはバインドやめるって言ってるよね
GUIはそんなもん表現できないし
エラー値が入ってくるならそもそもバインドって仕組み使わないほうが楽だよね

2021/01/24(日) 08:34:20.11

>>267
想像以上にレベルが低かったw
なんでvalidateの仕組みがないと思った？
https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2010/june/msdn-magazine-input-validation-enforcing-complex-business-data-rules-with-wpf
まあ、validateは色々なやり方あるし相互依存とかむっちゃ面倒になったりするからWPFも結構難しくて>>267あたりだと理解できないかもな

2021/01/24(日) 08:39:49.42

>>270
エアプ乙

2021/01/24(日) 08:58:35.15

>>268
自前でエラー内容を保持するしかないように思う
http://sourcechord.はてなブログ.com/entry/2014/06/08/123738
個人的にはViewModelに不正な値を入れるのは気持ち悪い

>>269,271
そろそろ黙った方がいいと思うよ
顔真っ赤すぎだろw

2021/01/24(日) 09:06:53.70

データバインディング使うのやめろやｗ

2021/01/24(日) 09:20:23.60

わざと新しい難解な方法を作ってるって発想はすげえな。
新しい方法使ってみたらわかるけど、なるほど、一部の課題は解決したな、みたいな感じになるだろうに。

2021/01/24(日) 09:22:49.58

ViewModelはModelではないんだから、別にエラーが入ろうが何でも良いだろ。
ViewModelからModelにするときにまとめてValidationしてるけど。
そうじゃないとそれこそ依存項目のチェックが出来んじゃん。

ViewModelとしてModelを使おうとするから変な話になるんじゃないの？

2021/01/24(日) 09:33:19.71

>>274
でもさ1つの値でうまくいってても他と絡みだすとそれじゃうまくいかんのよ
開始日と終了日は一例ね
ベース値と複数の差分値で表現してるものもうまく行かない
将来的になにかの値と関連する可能性があるならこの仕組みは入れないほうがいいかも？

データバインドっていう複数の値が連動するときにこそ役に立つ仕組みと思いきや実は鬼門とかいうおマヌケなお話（笑）

2021/01/24(日) 11:17:06.24

>>276
終了日のMaximunとMinimumバインドすりゃいいだけじゃね
開始日設定したらそこで変更すりゃ良い

2021/01/24(日) 11:20:17.45

>データバインディングしてる変数に間違ったデータが入るようにしちゃって大丈夫か？
大丈夫だろ
ビューモデルはあくまでビューの状態を表すんだから、ビュー(UI)の方で一時的に開始日と終了日が
ずれてもOKで別途最終確定ボタンみたいなUIを作るなら、
開始日と終了日の関係がずれた値(状態)になってもそれは

ビューモデル的には正しい値だぞ
モデル的には間違った値だけど

ちゃんと区別しよう

2021/01/24(日) 11:25:48.71

>>251
>WPF, Metro UI, UWPがコケた理由は単純に人、時間、金の投入量をケチって周到さが足りなかったからだと思うよ

いや
センスが無いだけだよ
どれだけリソース有っても創れない
あいつらの限界

2021/01/24(日) 11:33:52.77

ビューモデルはあくまでビューの状態を表すように設計するんだぞ

最終的なモデルの状態に不整合があったらまずいが、

ビューモデルはあくまでもビューの状態を表すんだから、一時的に不整合を許すUIを
設計するなら、ビューモデルもそういう状態になるだけだし
ビューモデルからしたら別に間違った状態じゃない

だから、
>逆にViewModelには正しい値しか保持しないとした場合、一時的にViewとViewModelで不整合が生じている状態になりますが、皆さんどのようにされてますか？
とか、前提がおかしいやろ。ビューの状態を表すようにViewModelつくるのに不整合を生じるようにつくるとか意味がわからん

2021/01/24(日) 11:47:47.30

>>278
それデータバインドいらないよねって言ってるよね？

2021/01/24(日) 12:13:40.42

ビューモデルに他にもテストしやすいとか利点あるだろ？
つか、数学じゃないから誰がもが納得する100%の
答えなんてないから君がそう思うならそう思えばいいと思う

2021/01/24(日) 12:18:43.65

データバインド捨てちゃえよ
楽になるぞｗ

2021/01/24(日) 12:28:41.42

MVVMがどうのって、今話題のMVUの話題絡みで出てきたのかと思いきや・・・・・なんも関係なかったぜ

2021/01/24(日) 13:48:48.78

>>276
うまく行かないか？
全部の値でやればいいだろ。
終了日と開始日、どっちにエラーメッセージ出す気なんだ？
俺は両方だと思ってるが。

>>281
要るだろ。
試験するときにUI生成しなくてもモックModelとのUnitTest通せるし楽じゃん。

2021/01/24(日) 14:24:10.62

>>285
そうやってエアプでできるできる言いたいなら言ってろ

2021/01/24(日) 14:40:58.72

>>286
エアプというか…普段使ってるから自信を持って出来ると言えるんだけど。
別にWPFだけではなくて、他のプラットフォームでもViewModel使ってるぞ。
自分に出来ないからといって、みんな出来ないのに出来るってフカしてると思い込むのは良くないんじゃないか？
複数の値が連動するときにこそ役立ってると思うんだが。違うのか？
鬼門だと一切思わん。
将来的に何か他の値と関連する可能性があるなら尚更じゃん。

なんでViewModelでエラーを表示してる状態が不整合なのか俺には全然わからん。

2021/01/24(日) 14:50:18.37

>>287
じゃあ、>>263と>>267をどうやって実装してんの？

開始日と終了日なんて普通にアプリ組んでて出てこないわけないよね？
やったことあるんでしょ？

2021/01/24(日) 15:02:34.21

>>288
普通に入力可能にして、エラーメッセージの表示条件が、開始日＞終了日であること。
保存チェックはエラーメッセージが一切表示されていない事。Modelには一切波及せずViewModelで完結する。
仮保存のみOK。仮保存はViewModelのうちシリアライズしてはいけない項目を殺して保存。

入力中に一時的に入れ替わるなんてよくある事なんだから、いちいち選択不可にしてたらユーザビリティ悪すぎでしょ。
開始日がデフォルトで今日～空白の時に、一昨日から昨日までの値を入れるのに、いちいち開始日から入力させんの？アホらしいじゃん。
入れ替わった時点でエラーメッセージに「開始日と終了日が入れ替わっています」と出しておけば一発でしょ。ついでに保存ボタンのEnabledも変えとくと親切だな。

エラーメッセージも、保存ボタンのEnabledも、両方ともプロパティにバインドしとけば、値を変えるだけで制御も変わる。便利よね。

2021/01/24(日) 15:03:44.94

まさか今どきエラー項目をダイアログ表示するとかいう発想じゃ無いだろうな…。

2021/01/24(日) 15:04:38.53

>>289
それがVMの役割だよなぁ
VMはViewの値をバインドしてるんだから、どんな値だろうと関係ない。
VMにバインドされた値が範囲外なら赤枠などで注意を促し、保存ボタンを押せなくする。
モデルに渡すときに仕様の範囲内であればいい

2021/01/24(日) 15:05:11.26

え？できたん？
ちょっとよくわからなかったけど

2021/01/24(日) 15:06:12.10

>>291
まさにそう。
ボタン一発でデフォルト日にしたい、なんて要件が生まれたら、Commandをバインド。
わかりやすいと思うよ、俺は。

2021/01/24(日) 15:07:13.99

>>292
何がわからんかった？

2021/01/24(日) 15:08:16.18

>>294
え？値が範囲外で保存できちゃう？

2021/01/24(日) 15:09:00.14

>>295
保存ボタンがDisabledなので保存のしようがないだろ。

2021/01/24(日) 15:09:38.35

それでもできる仮保存は、ViewModelの保存であって実データではない。画面保存。

2021/01/24(日) 15:10:40.00

>>296
チェックしなくしたん？
開始日と終了日の個別のバリデーションはあったら動くん？

2021/01/24(日) 15:11:59.27

>>297
え？それもうデータバインドいらねーじゃんｗ
まあ、でも俺はその結論で満足だぜｗ

2021/01/24(日) 15:12:28.56

>>298
チェックしてるじゃん。
プロパティが変わるたびにチェックされるよ。
された結果エラーメッセージが確定して、エラーメッセージが確定したら保存ボタンのEnabledが確定するでしょ。
個別のバリデーションは好きにやれば良い。同様にエラーメッセージを吐いとけば、エラーが一つでもあれば保存ボタンがDisabledになるんだから問題無い。

2021/01/24(日) 15:13:36.69

>>299
要るじゃん。UIコード一切触らなくても、バリデーション増やせばエラーメッセージを増やせるんだぞ。
そしてテストはViewModelで完結する。

2021/01/24(日) 15:15:55.11

データバインドできるから、画面保存が、不要な項目を殺す程度の実質ただのシリアライズで実現できるんだけどな。

2021/01/24(日) 15:17:35.09

開始日、終了日ダイアログボックス表示してOKボタンで値を保存するんです？

2021/01/24(日) 15:20:53.63

>>303
開始日の横、終了日の横に、エラーメッセージを表示するラベルを置いてバインディング、
必要ならエラー項目は赤地なんかにしてもいい。
HasErrorもあるし、IDataErrorInfoもあるだろ。
好きなクラス作っても構わん。

2021/01/24(日) 15:23:17.99

保存とチェックはOKボタン？

2021/01/24(日) 15:24:54.20

UNDO UNDO REDO REDO OK？

2021/01/24(日) 15:27:25.67

チェックは自動。PropertyChanged使ってもいいし、ReactivePropertyでも良い。
保存は保存ボタン。
Undo、RedoはViewModel保存してれば良いじゃん。

2021/01/24(日) 15:28:32.34

キャンセルボタンで開始日終了日ダイアログ表示前の値だろ当然

2021/01/24(日) 15:31:18.19

>>308
ダイアログなんか出さねえよ。
間違えたらCtrl+Zで良いじゃん。
入れてる途中の数字を無理矢理戻されて気持ちいいわけ無いじゃん。

2021/01/24(日) 15:32:19.23

何？202/01/02って打ったらダイアログ出てきて2020/12/31にゴリ押しで戻されるようなのが良いの？
明らかに1だけ入れたほうが楽じゃん。

2021/01/24(日) 15:32:58.24

え？範囲チェックいつするの？

2021/01/24(日) 15:33:11.21

>>311
いつでもしてる。

2021/01/24(日) 15:34:40.08

じゃあ、エラーでたままを許容するんだ？

2021/01/24(日) 15:35:20.11

ViewModel使ってないから、プロパティ変更時にチェックかけるって発想が無いんだろうか。
ボタンクリック時に、if(xxx.Value)...ってひたすら列挙してんのかな。

2021/01/24(日) 15:35:48.04

その間、GUIのグラフにはどう出しておけばいい？

2021/01/24(日) 15:37:14.85

>>313
ViewModelが「エラーを表示している」ってのは正常系。
Modelの開始日終了日は一時的にも逆転することは無い。
なぜならViewModelが「エラーを表示している」状態からは、Modelは生成されない。

Modelにエラー出たままは許容しない。
ViewModelにエラーが出てるのは正常系。許容も何もない。

2021/01/24(日) 15:38:28.95

>>315
そのレンジのグラフを表示するなら「描画できません」一択だろ。
業務アプリなら、画面入力しようとしたら一旦グラフ消すだろうし。
そうしないと、入力中のスクショ送られてきて混乱することになるぞ。

2021/01/24(日) 15:40:59.68

入力がおちつくまでグラフを描画しない、をやりたければReactivePropertyの方が楽だな。

2021/01/24(日) 15:47:17.96

>>317
えー、死ぬ
たったこれだけのためにそれ用の処理用意すんの？ｗ

2021/01/24(日) 15:52:16.29

>>319
バインディングしてれば、グラフと「描画できません」って書いたラベルの2つのVisibleをひっくり返すだけで良かろう。
なんの処理も無い。むしろ楽になる。

2021/01/24(日) 16:05:06.18

一応言っとくが、びっくり返すのも直接Visibleを変えるんじゃなくて、Visibleにエラーが有るか無いかから算出されるプロパティをバインディングすれば良いからな。

2021/01/24(日) 16:11:45.64

データバインド使うためだけに余波が物凄くね？
開始日と終了日のエラーを許容してる間って他の値を変えたときはそっちは保存するの？

2021/01/24(日) 16:18:07.86

ViewModel使う事によって余波が減ってると思うが。

他の値は他の値でバリデーションかけたら良いだろ。
保存されるも何も、Modelとしてされないよ。一部がおかしいデータは全体として必ずおかしいだろ。
ViewModelとしては一時保存したければするかもしれんが、Modelにはならん。
その別のデータとやらが開始日と終了日に挟まれているべき日付、なんかだったらそもそもの定義が揺らいでくるじゃん。
全部Leaveするときにチェックするの？コントロール順とか、入力バリデーションに引っかかる順番ごとにテストする？組み合わせ爆発するし、ダイアログが出るかどうかなんてテスト、自動化しづらくて仕方ないじゃん。

明らかに、ViewModelとして帳尻が合ってるかをチェックする方が確実だし効率的でしょ。

だから許容も何もない。

2021/01/24(日) 16:46:04.32

いや、UNDOどうなん？
本格的にエラー値を保存しちゃうの？

2021/01/24(日) 16:53:34.11

エラー値をViewModelとして表示するし、一時保存もするだろう。
Modelは保存しない(できない)から問題無い。
エラーも含めてUndo、Redoできて何かおかしいか？

未入力　 2020/12/31
2021/01/02 2020/12/31
2021/01/02 2021/02/21
全部Undoすれば良いじゃん。
俺がよく使うのは、Undoはコントロールレベルに留めて、「入力破棄」とか「再読込」ってボタンを用意する事だけど。
変更はViewModelに留まってるから、普通に破棄してModelから再読み込みしてViewModel再構成したら終わる。

開始日終了日は確定してないけど一部だけ変更されたデータなんかを保存するつもりなの？

2021/01/24(日) 17:00:54.66

ViewModelにエラーを表示している状態を保存してなんの問題があるんだろう。
実データとは全く関係ないデータなんだが。
そのあと修正して確定させないとModelに落ちないなら問題なくね？
いっつもそうして「仮保存」やってるんだけど。
番号取っとかないとダメとかはまた別のやり方するけどさ。

2021/01/24(日) 17:51:29.07

twitterでやれ

2021/01/24(日) 17:55:17.05

この間別の正しい値はmodelまで保存できるの？
開始日と終了日に関わるすべての値が保存対象でなくなる？

2021/01/24(日) 18:03:41.68

何を争ってるのかいまいちよく分からないけどずいぶん盛り上がってるね。

さすがに誰かタオル投げた方がいいレベルのような気がするけど
こういう時はなぜかだんまりなのねw

2021/01/24(日) 18:06:22.86

続きはこっちでどうぞ

WPF(.NET4.x, .NET Core) GUIプログラミング Part24
https://mevius.5ch.net/test/read.cgi/tech/1575862574/

2021/01/24(日) 18:18:42.23

>>329
実はみんな開始日終了日のデータバインドの解決方法が知りたかったけど
エラー値許容でがっかり回答だったと思う
エラー値許容は他の箇所での対処に追われるからできればやりたくないだろ

2021/01/24(日) 18:19:27.82

>>328
一つのModelに開始日終了日とその別の値が入ってるなら保存するべきじゃないし、保存しないと思うぞ。
開始日終了日に関わるんじゃなくて、その画面上に表示されてるデータが確定できるデータじゃないでしょ。
正しい値でもなんでもない。

あのさあ。結局データバインディング使ってどう解決したら良いか知らないから、データバインディング使わないほうがお前の場合良いって事にしかならんでしょ。
エアプそのものじゃん。

2021/01/24(日) 18:20:37.83

>>331
そのエラー値のデータは、確定されない、永続化されないから対応に追われることは無いよ。
だからViewModelに閉じ込めるんであって。
ViewModelとModelを区別できて無いじゃん。
何聞いてんの？

2021/01/24(日) 18:23:05.74

がっかり回答どころかがっかり理解力だわ。
俺が間違ってるなら指摘してくれ。

2021/01/24(日) 18:25:54.36

いや、だったらデータバインドいらねーじゃん
だってそれ普通にダイアログ出してOKボタンでチェック＆保存してんのと変わらんもん

なんかいい方法を知ってる神が舞い降りるのをみんな待っているのさ（笑）

俺はデータバインド使うのやめたけどｗ

2021/01/24(日) 18:38:06.15

>>335
UI層変わったらどうすんの？
WPFからUWPやXamarinなんかに移植するとき、全部コントロール貼り直して、コントロールへの値のSet,Get全部やり変えて、全部テストすんの？
新しいUIフレームワーク出たら？

アホでしょ、常識的に考えて。

2021/01/24(日) 18:39:44.53

テストするときにモックのUI差し替えて自動テスト出来るんだけど。

最終的には結合試験するだろうけど、その前の段階でも画面ポチポチしながら決定表みてテストしてくの？

工数の無駄遣いでしょ。

2021/01/24(日) 18:45:29.80

元はデータバインディング使うと上手く行かないことがあるって話だったのにすり替わっているな

2021/01/24(日) 18:47:17.74

>>338
うまくいってねぇじゃん

2021/01/24(日) 18:50:14.09

NGでスッキリ

2021/01/24(日) 18:50:33.38

横からだけど
いままでMVVMの意義が理解できてなかったのがID:3jwmj/rb0の説明で開眼したかもしれない

WPFスレで聞くべきかもしれないけど、
View＝ViewModelの保持値を表示する＆入力値が変わったりボタンが押されたらViewModelの当該プロパティやメソッドを呼び出すだけの存在
　（決してビジネスロジックやバリデーションをView自体に持たせてはいけない）
ViewModel＝画面上のいろんなTextBoxやLabelのTextだったりButtonのEnabledだったりを一元的に保持することだけを担う存在
　（エラー入力値なんかもあるがままに保持すべきであり、
　　ViewModelでバリデーションチェックを行ったうえでバリデーションNGとかの結果もエラー表示項目の値としてセットすべきである）
Model：極論してしまえばView/ViewModel以外のビジネスロジック的な処理すべて
（UIに依存しない処理は全部Modelで書く）
っていう理解でおおむねあってる？

なんとなくだけど、上記の考え方なのだとしたら
そもそも ID:H0Ke+o4H0 の人はMVVMでなかったとしてもMVVMでいうModelとそれ以外の処理もごちゃ混ぜで書いてそうな印象

2021/01/24(日) 18:59:46.81

>>341
開始日と終了日エラーでたままじゃグラフの表示範囲も決まらんかもしれんのによくやるわ

ビジネスロジック入れないでグラフの表示範囲計算できると思ってるのかよ
夢見んな
んでエラー値許容のまま放置できちゃったらエラー箇所ユーザにわかるのかよ的な
visualstudioだって一発ビルドしないとエラー箇所わからん

ボクはうまくいってないと思います

2021/01/24(日) 19:01:12.31

やっぱり何の話をしてるのかよく分からんけど
UI上の値がモデルに今反映されているのかどうかはっきりしないUIはイラッとくるね。

UI上の値がモデルに反映されていない状態を許すなら>>335が言ってるように
ダイアログ出してくれる方がフレンドリーだと思う。

許さないならUI上の値も常に不整合を許すべきではないと思う。
数直線上の閉区間（a≦x≦b）を入力するUIがあったとして、
ユーザーによるaの入力が確定した時a>bになっちゃってたらb = aに変わるべき。

2021/01/24(日) 19:05:57.47

WinFormsのコントロールは内部状態を抱え込んでたんでテストが面倒くさかったのを
VMで外出しにした、というくらいに理解しておけばいいと思う。

バインデングいらないの人はFormsじゃあどうしてたんだろうか。

2021/01/24(日) 19:09:39.64

？？
グラフ表示に必要な項目が入力エラーなら「日付が間違ってるのでグラフが表示できません」ってテキストで表示するだけだと思うんだけど

ていうか>>342のいう「グラフ作成」がbmpみたいな画像生成を指すのであれば
その処理はたぶんModelで持つのが正しい気がするし、
View/Modelが密接不可分に結合するような処理であれば
わざわざViewとModelの分離を意図してる（で合ってるよね？）MVVMにしないほうがいいのは当たり前の話だと思う

2021/01/24(日) 19:57:04.13

>>341
値にしなくてもプロパティとして表現すると読み書きの方向がはっきりするし良いよ。特にEnabledとかは。

>>342
表示範囲が決まってないのに、グラフが表示できるわけないんだから、「現在描画できません」って表示するのは正でしょ。
ビジネスロジックに通したとしても、それをModelとして保存するかどうかは別問題。

エラー値許容って考え方がおかしい。
エラー箇所がわかるようにバインドするのであって、
各変数がバインドできてるかはモックViewModelを使ったUIテスト、
各種バリデーションがきちんと発生するからモックUIを使ったViewModelテストで、疎に担保するべきもの。
コンパイルエラーとかそういう次元ではなくてUnitTestぐらい通すだろ、普通。
責任範囲がまぜこぜじゃん。

>>343
業務アプリで、画面表示中の項目と、入力項目が不一致になるのは禁忌に近いんじゃないかな。
スクリーンショットからトラブルシュートするのがほぼ不能になる。

>>345
そのグラフ作成、Modelではなくて、切り出しておくべきでは？
結局のところ、一定範囲のデータを与えられて、グラフを描画するって関数なりコントロールになって然るべきだと思うよ。
内部的にbmpを生成しようが、画面に描画する以上。
そうしといたら、グラフコントロールを差し替えたい時に気楽に差し替えられる。

2021/01/24(日) 20:50:20.30

>>338
だって出来ない理由がvalidateなんだもん
そりゃ本人の能力だよねってなるわw

2021/01/24(日) 20:57:17.36

>>346にある「プロパティ」って他言語でいうComputed Property(ごめんC#で何て言うか分からない)のことでいいのかな
であれば（and>>344の理解で良いなら）MVVM完全に理解した
ただしく適用すればソースコードの見通しがめちゃくちゃよくなるだろうと思いました
といっても普段の開発がWinFormsかASPNETCoreばっかりなんで活かせる機会なんて来ないんだけどさ

グラフ作成はViewやViewModelに押し込むくらいならModelに置いてくれと思ったけど
別に切り出せるならそのほうがもっと良いのはごもっともです
層分けって大事だよねー・・・と普段メンテしてるようなソースを思い起こしながらため息をついてみたり

2021/01/24(日) 21:15:16.63

>>348
C#でプロパティって言えば迷うはずないだろ

2021/01/24(日) 21:27:56.19

プロパティと聞いて「自動プロパティ」のほうがまっさきに思い浮かんじゃって
「自動プロパティじゃないほうのプロパティ」の呼び方が分からなかったんだけど・・・
何て呼ぶのが一般的なのかな

2021/01/24(日) 22:00:13.52

>>341
あってます。
ViewModelは具体的なUIを持たないViewだと思えば良いです。
なのでVisible等のViewに関するロジックはここが持ちます。

ViewはViewModelをそのまま具体的なUIで表現するだけです。

2021/01/24(日) 22:02:48.96

プロパティ、そりゃどれもプロパティだな、言葉足らず申し訳ない。
Computed Propertyググった。
そう、これの事。値を持たず他のプロパティの内容から算出されるプロパティ。

2021/01/25(月) 08:56:15.41

いい加減こっち行こうか

MVVMについて語ろう
https://mevius.5ch.net/test/read.cgi/tech/1338948213/

2021/01/25(月) 12:28:32.14

ちゃんとスレあるんだな。
すまなんだ。

2021/01/25(月) 12:49:25.57

いえいえ

2021/01/25(月) 20:38:53.42

プログラマできちんと反省できる人はレア。

2021/01/26(火) 08:08:46.68

プログラマが反省してたら精神がもちません

2021/01/28(木) 12:09:38.85

Enumerable.OrderBy メソッドを呼び出す際に、
引数に送るデリゲート（Func<TSource,TKey>）を動的に指定したい。

具体的には、
List<Person> people = new List<Person>(basePeople.orderby(person => person.名前))
といった並べ替え処理を、Personクラスの各プロパティについて行いたい。
（年齢、整理番号、生年月日など）

現在はそれぞれのプロパティ（20以上）について上記メソッドを作成して
やりたいことは実現していますが、全くスマートじゃないです。

propertyinfoクラスを使って何かできないかと思ったんですが、
デリゲートの中に組み込むような使い方が全く思いつきませんでした。

どなたか分かる方教えて下さい。

2021/01/28(木) 12:59:34.80

Syatem.Linq.Dynamic

2021/01/28(木) 13:42:24.38

>>358
ひょっとして問題を誤解してるかもしれんけど、
OrderByのセレクターは使わずにIComparerで渡す
オブジェクトの方に実質的なセレクターの機能も兼任させれば
できるんじゃないの？