WPF(.NET4.x, .NET Core) GUIプログラミング Part24

2019/12/09(月) 12:36:14.49

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

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

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

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

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

2021/01/26(火) 14:40:20.88

>>812
ASP.NET Core MVC

2021/01/26(火) 15:00:30.94

Web APIならね。UIが必要ならそこはRazor Pagesにしときな。

2021/01/26(火) 20:34:15.63

>>802
Win32レベルでいいならC++/CLI以外みんな生き残るだろ。

2021/01/26(火) 20:38:42.61

>>803
「作れる」のレベルはだんだん上がってきているけどデスクトップフレームワークの域にはまだ遠いよなぁ。
BlazorでWPF動かせるようになったらいいんだが。

2021/01/26(火) 21:13:38.65

>>817
Blazorはjs書けない層の
救済ライブラリーですよ。

2021/01/26(火) 21:19:33.80

>>818
Cはアセンブラ書けない層の救済言語、みたいな？

2021/01/26(火) 21:24:27.11

>>819
ちょっと違うかな。
js<-->c#のラッパーライブラリーになります。
なので遅くて機能も少ないです。

2021/01/26(火) 21:33:10.40

そういう話じゃなくてね、>>818はC#よりJSの方がハードルが高いと言いたいのかってこと。

2021/01/26(火) 21:39:57.47

>>820
さすがにデタラメすぎワロタ

2021/01/26(火) 21:41:41.11

>>821
それは人によりますね。

>>819
アセンブラ書ける層にもｃ学ぶメリットがありますが、
（ｃはアセンブラ書けない人の救済目的でない。）
jsでwebアプリ開発者出来る層が、
Blazor学ぶメリットは無いって事です。

2021/01/26(火) 21:55:22.08

>jsでwebアプリ開発者出来る層が、
>Blazor学ぶメリットは無いって事です。

つまりWebアプリの方がハードルが高いって言ってるんだろ？

2021/01/26(火) 22:41:31.51

いやBlazorが糞って言ってるんだろ

2021/01/26(火) 22:51:00.14

webアプリメインでやってりゃ
デスクトップアプリ開発なんて未知の領域だし
逆もまた然りでしょ。

つってるうちに、
web開発者がそのスキルの延長で
デスクトップアプリ作り始めてるって時代に
なっちゃってますけどね。

因みにスマホアプリも業務系は
かなりの部分的がwebView使った
webアプリですわ。

2021/01/26(火) 23:55:27.32

結局デスクトップアプリやりたかったら何勉強したらいいんだよー

2021/01/27(水) 00:03:20.45

GDI

2021/01/27(水) 06:04:27.12

>>827
UWP

2021/01/27(水) 07:57:56.27

UWPはいいね
この前ストアアプリ配信したんだけど結構ダウンロード数伸びてる大したことないアプリなのに
まだマイクロソフトストアが未成熟だからね
すでに飽和してるApp StoreやGoogle Play Storeじゃこうはいかない

マイクロソフトストア狙い目よ

2021/01/27(水) 08:05:32.37

Web(React)もデスクトップ(WPF)もやってるが、だからといって今のReactで
デスクトップアプリ作る気にはなれんな。

>web開発者がそのスキルの延長で
>デスクトップアプリ作り始めてるって時代に

自分が持ってるスキルで他分野に入り込みやすくなったから
喜んで使っているんだろうが、これから新しくデスクトップアプリを
始めようって人に勧めるのはちょっと違うかな。

2021/01/27(水) 08:28:30.65

趣味の開発なら良いが業務用アプリでUWPを使おうとは思わんな

2021/01/27(水) 09:09:15.94

でもさ趣味と業務で技術を使い分けるのも非効率じゃない？

2021/01/27(水) 09:16:51.18

趣味はある程度妥協できるけど、業務はそれができない

2021/01/27(水) 09:18:43.10

>>833
業務用には枯れたものを使いたいねえ
最先端も追っかけなきゃ技術者としては終わるけど

2021/01/27(水) 09:31:24.47

いまさらUWPはやめとけ

2021/01/27(水) 09:34:14.87

マイクロソフト環境にどっぷり漬かっている会社ならビジネス向けストアを使う手もあるだろうが
IT部門が全社に配布する手間を減らせる以外のメリットが思いつかんな。
まさか常にサイドローディングしてもらうわけにもいかんだろうし。

2021/01/27(水) 09:45:27.80

新規だとWPFですかねえ
winformよりはUWPへの乗換ハードルは低いし
webじゃ無理なアプリもあるし

2021/01/27(水) 09:47:08.33

デスクトップ　ExcelVBA
Web　スプレッドシートGAS

2021/01/27(水) 11:58:47.28

今から投資するなら
.NET MAUI
かな。xaml + mvvm が糞すぎた。

2021/01/27(水) 12:01:39.36

全く詳しくないんだけどWINUIは糞なところは改善されるの？

2021/01/27(水) 12:34:09.96

良く判らんが、ザマリン下位のskia
をGDIでラップ出来るようになったの？

2021/01/27(水) 13:27:12.09

UIがどうなろうとIPropertyChangedは全部書かないといけませんか？

2021/01/27(水) 13:34:31.78

>>843
必要でしょう
ReactivePropertyとかBindableBaseを使えばコーティング量が減る

2021/01/27(水) 13:36:55.01

>>843
MVUなら必要ないよ

2021/01/27(水) 13:52:55.21

うーん
プロパティにref使えないけど
SetPropertyどうやって使ってんの？

2021/01/27(水) 13:53:49.65

.NET MAUIか

2021/01/27(水) 13:54:43.18

>>846
え?

2021/01/27(水) 14:09:18.65

xaml登場時からやってる
ベテランの自分でさえ
xaml流mvvmは
コード量が激増して面倒臭すぎる。

ReactのJSXみたいに
xaml中にコードが直接かけるように出来んものか？

2021/01/27(水) 19:59:46.88

<x:Code>で囲めばゴリゴリC#書けるよ
面倒だから素直にコードビハインドに書いた方が早いけど
どうせg.csにコピーされるだけだし
まあ何につけmvvmが失敗の原因だったよね

2021/01/27(水) 21:48:06.42

失敗というか、WPFに挫折した人の原因ではあるのかもしれない。

2021/01/27(水) 22:50:02.01

VisualStateManagerはBlend前提の設計かもしれんが、ちょっと解りにくいわな

2021/01/27(水) 22:51:44.29

MVVMってテストしやすいのはいいけど、設計難易度上がるし面倒なところあるから初めて関わる人や新人いるチームだと大変すぎてな。一人や少数精鋭チームでやれればいいけど。

2021/01/27(水) 23:11:30.32

ビューとモデルの完全分離を目指した結果
肥大化するコードと失われる可読性って本末転倒じゃん

2021/01/28(木) 07:46:28.72

>>849
xamlてコード分離が目的なのに中にコード書いたら意味無いような気がするが

2021/01/28(木) 10:15:55.24

>>855
コードを分離する
メリットとデメリットは？

2021/01/28(木) 10:19:43.92

>>856
メリット、ユニットテストがやりやすい
デメリット、めんどくせー

2021/01/28(木) 10:26:33.10

>>857
ユニットテストは
やりやすいレベルにはならんよ。

2021/01/28(木) 10:27:16.51

なるよ

2021/01/28(木) 10:28:56.03

ならん！

2021/01/28(木) 10:40:26.08

>>858
UIベッタリだと出来ないだろう

2021/01/28(木) 10:59:29.17

>>854
Railsですね判ります

2021/01/28(木) 11:27:11.16

コード増えるのは辛いよな
なんとかならんのかこれ

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

model view を結合するのはいいけど、、

model もうひとつつくって、プログラムされたタイミングで
同期させたい

isDirtyな
double bufferともいう

2021/01/28(木) 12:22:12.52

INotifyPropertyChanged実装しないModelクラスを、ViewModelでラップするのがしんどい。

2021/01/28(木) 12:25:43.67

mv結合100%だから不自由なんで、

設計でいうmodelとは別に
実装用のmodel作るべき

設計modelは切り離して
change by user
change by initialize
change by signal
も判別しなきゃだな

2021/01/28(木) 12:47:51.29

>>863
mvvmを捨てる事から初めてみましょう！

2021/01/28(木) 20:10:35.14

>>854
俺の言いたいことをすべてお前が大便してくれた

2021/01/28(木) 20:52:41.82

>>861
FormsアプリをUIAutomation使って自動テストする地獄を味わったことのない人には
有難みがわからないのだろうな

2021/01/28(木) 21:24:14.10

そもそも>>858はユニットテストがなにか知らんような気がする
マニュアルに従ってテキトーにポチポチクリックして落ちなきゃテスト終わりーとか言ってそうw

2021/01/28(木) 23:14:26.37

>>870
今時ICサーバー必須と言われてますわ。

2021/01/29(金) 05:32:11.60

ICサーバーってなんだ？
まさかと思うけどCIサーバーのことじゃないよな？w

2021/01/29(金) 12:45:43.37

笑

2021/01/29(金) 19:43:57.28

>>870
俺は>>858じゃないけど、
マジ、おせーて
assertとか使う奴？
それともGUI上で出来るようなのがあんの？

2021/01/30(土) 10:03:36.71

>>855
ビジネスロジックコードの分離が目的なのだから、デザインコードは一緒になっている方が良いかも

2021/01/30(土) 12:20:17.91

Javaでオブジェクト指向が流行った時期の間違いみたいに
大規模開発専用のクソ仕様を銀の弾丸として全部に使おうとして失敗してる感じに思える

2021/01/30(土) 13:07:37.17

アニメをデフォルトで使う分にはxamlってそれほど複雑でもないんだけどね
formsと同じことやるなら

2021/01/30(土) 14:21:59.06

UI作る人と分業できるって言うけどどんだけ凝った画面にすんだろ。
結局はコード書く人が画面まわりもやってね?
最近違うの?

2021/01/30(土) 15:34:49.92

専業のUIデザイナー雇ってるとこなんて余程の大手だけだろうな

2021/01/30(土) 15:56:17.98

xaml書く専業デザイナーって聞いたことないけどいるの？

2021/01/30(土) 17:17:04.26

UIとコード別けられるのが最大のメリットという位だしな。
居ないとおかしいがな。

2021/01/30(土) 17:34:35.97

誰が言った言葉かは知らんが、少なくともUIデザインを別担当者にできるのが
最大のメリットだということじゃないと思うぞ。

2021/01/30(土) 18:58:30.27

何がメリットなのかWPF素人にはサッパリだよ。

2021/01/30(土) 19:40:15.77

俺個人としてはxamlでレイアウトしやすいところとmvvmでテストしやすいところかな。

2021/01/30(土) 19:46:33.44

デザイナーがHTML/CSSで作ってプログラマーが同じ見た目になるようにXAML書く

2021/01/30(土) 19:52:36.52

デザインとプログラミングの分業においては遥かに先を行っているはずのWebでは、
最近は逆にJavaScriptにインラインでHTMLを書いているのでした

2021/01/30(土) 20:01:29.27

>>885
初めからデザイナにXAMLで書いてもらったら?

2021/01/30(土) 21:55:15.69

>>887
XAML書いてくれるデザイナーなんているの？

2021/01/31(日) 00:20:30.44

作業としてUIとコードを分けられることがメリットじゃなくて
そこが疎結合になるからいいんでないの

2021/01/31(日) 01:07:23.46

疎結合になること自体はメリットではない
疎結合になることで何がメリットになるか書かないと

結局、分担作業やデバッグが楽という話に落ち着くと思うが

2021/01/31(日) 01:25:53.85

疎結合のメリットがわからない人はここにいるのかい？

2021/01/31(日) 01:40:01.70

疎結合になること自体はメリットではないことがわからない人がここにいるのかい？

2021/01/31(日) 01:46:06.04

個人とか小規模開発ならあんまメリット大きくないよな

2021/01/31(日) 07:07:48.07

どんだけでかいシステム作るんだろうな。
VC6.0やVB6.0でいいだろと言いたい。あれは良くできてた。

2021/01/31(日) 07:27:03.47

>>891
疎結合のメリットを教えてください

2021/01/31(日) 07:51:13.66

疎結合って
キチンとインターフェース決める設計手法と
ほぼ逆の事をやってるね。

VS等の参照ジャンプが利かなくなって
かつリファクタリング機能の対象外となるし、
コンパイル自分に結合保証も担保できなくなるから、
大規模化リファクタリング後の
潜在バグの原因になっとるんだが。

2021/01/31(日) 07:53:58.88

>>890
疎結合だとデバックが楽というの
どんなケースを想定されてるのでしょうか？

2021/01/31(日) 08:06:25.92

疎結合だとデバッグが楽・・・
ビューとモデルが明確に分離されてることで
「画面に表示される値がおかしい！」というときにまずはモデルをチェックすればいい
だいたいこれで誤りが見つかる

ビューはモデルを素直に反映するようになっていればビジネスロジックの影響をほとんど受けない
つまり、デバッグ（点検）対象から外せるケースが多くなる

2021/01/31(日) 08:36:11.85

>>898
Viewとmodelの分離は
疎結合は関係ないんじゃ...

「ビューはモデルを素直に反映するように」
これも...

2021/01/31(日) 09:12:12.67

ViewとModelの分離で結合が疎にならないの？
>>899の思ってる「疎結合」の定義を聞かせてほしい

「ビューはモデルを素直に反映するようになっていれば」という前提の整理について
>「ビューはモデルを素直に反映するように」
ここだけ抜き出して「これも..」と指摘してるのはいったい何が言いたいの？

なんか逆張りで根拠もなくケチつけてるだけに見えるんだけど

2021/01/31(日) 09:17:07.25

昔の方が作りやすかった気がする。

2021/01/31(日) 09:19:16.44

>>897
自動テストの話じゃないの

2021/01/31(日) 09:21:31.64

>>900
「密結合してViewとmodelを分離」
「密結合してViewとmodelを素直に反映」
しても結果は同じでは？

2021/01/31(日) 09:28:45.68

？？？
ごめん>>903の国語力か俺の国語力かどっちかに問題があって
あなたの主張したいことがわからない

で、あなたの思ってる「疎結合」の定義について説明をお願いしたいんだけど

2021/01/31(日) 09:29:51.76

>>901
昔というか、
WinFormsと同じようにWPFでも書けるよ。

実際サンプルコードはコードビハインドで
イベントハンドラーで書いてあるもの多い。

2021/01/31(日) 09:34:58.64

>>905
mvvmのサンプルじゃ無きゃ
イベントにベタ書きのサンプルだらけ

2021/01/31(日) 09:43:32.25

>>904
良い説明をググッてみたけど
見つからないので簡単に書くと、

コンパイル時に参照が切れた状態になる実装を
疎結合。WPF流MVVMでバインディングで繋ぐと疎結合になる。

対してC#で普通に書くと密結合。

2021/01/31(日) 09:48:53.55

ちなみにMVVMで
XAML(View)とmodel間の接続を、
例の難解なバインディング構文を使わずに
コードで書く(密結合)事もできる。

2021/01/31(日) 09:49:01.23

>>905
それで売りの高解像度にも対応してるなら
それでいいやね。

>>906
MVVMもそのうち消えるだろう。

2021/01/31(日) 09:50:58.51

>>908
バインドが難解だと?

2021/01/31(日) 09:53:51.31

>>910
初心者には難解じゃない？
コード補完も効きにくいし。
最初の多きな(大きすぎる)ハードルでしょ。

設定間違えると動きも変わるし。

2021/01/31(日) 09:59:52.50

ビューとモデルの分離って、ロジックに影響なく簡単に見た目を変えられることにあると思うのだが

2021/01/31(日) 10:01:10.65

>>909
>>MVVMもそのうち消えるだろう。

MVPの派生だし消えるほど酷くはないけど。
自分はReactとかでViewModelとかいう概念は
便利に使わせてもらってる。

View(React,ts)+ViewModel(ts)+Model(C#)

2021/01/31(日) 10:01:25.28

>>911
コード量は増えるけどバインド有ってのXAMLでしょう。