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/08/21(土) 20:36:30.51

旧版にあたるWPF4.5入門（https://www.slideshare.net/okazuki0130/wpf45-38048141）と
見比べてみれば、まだまださわりの部分だわな
つか、現状に合わない部分を削除してるだけに近いかね
まだ加筆が必要な部分じゃないからだろうけど

**デフォルトの名無しさん** · 2021/08/21(土) 21:03:06.13

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/21(土) 22:01:00.51

>>675
こういうのじゃないの？
https://zenn.dev/apterygiformes/articles/79a7c9e7e15106

**デフォルトの名無しさん** · 2021/08/21(土) 22:05:08.07

>>675
https://emu2021makuake.github.io/MVVM-Samples-Index/

**デフォルトの名無しさん** · 2021/08/21(土) 23:02:56.36

>>678
これは参考にしたけど途中でモデルがない？ってなったやつだわ。
>>679
こっちは見た事ないからちょっと勉強させてもらいます。

**デフォルトの名無しさん** · 2021/08/22(日) 04:37:08.19

こういうの見て正義に成ったと勘違いして
糞コード量産タイプになんだろな

reactとかだと1/10以下のコード量だぞおい

**デフォルトの名無しさん** · 2021/08/22(日) 08:24:41.03

>>680

>例えば計算機レベルのサンプル
>
>厳密に3つの責務(View, ViewModel, Model)に分けた所でPDSの冗長さが目立つだけです。
>計算機程度の小規模であるならば、ViewModelをModelと統合するのは大抵の場合あるべき姿です。

https://slidesplayer.net/slide/11235164/

**デフォルトの名無しさん** · 2021/08/22(日) 10:06:31.28

>>681
趣味で盆栽的にやってるもんだから特に発信する気もないし誰にも迷惑かけんから勘弁してよ。

>>682
数日前にこのスライド読んで、今はMVCやMVPから調べ直してるところだわ。

**デフォルトの名無しさん** · 2021/08/22(日) 13:08:52.90

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 20:28:25.21

>>684
隔離スレから出てこないように

**デフォルトの名無しさん** · 2021/08/23(月) 04:16:34.70

>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった

**デフォルトの名無しさん** · 2021/08/23(月) 04:16:35.32

>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった

**デフォルトの名無しさん** · 2021/08/24(火) 15:32:26.18

秘伝のへたれ

**デフォルトの名無しさん** · 2021/08/24(火) 20:56:36.64

>>687
たった1週間程度だけど調べてサンプル写経して、WPFで用意されたデータバインドと各インターフェースを用いてオブジェクト指向で作ったのがMVVMになんのかなと、とりあえず理解した。
WPFでMVVMって秘伝のタレというより、作り手の匙加減で決まるお袋の味みたいなもんか。

**デフォルトの名無しさん** · 2021/08/24(火) 21:49:09.60

MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
MVVMのベースとなるｐｒｉｍｓやMVVM Toolkitなどのライブラリはそっちで必要なDIやマルチキャストのイベントなどの機能も盛り込まれています
Windows template studioというMSによるVSの拡張機能でこれらを使った雛形でアプリを作れるけど、生成されたアプリを眺めていけば見えてくるんじゃないかな

**デフォルトの名無しさん** · 2021/08/24(火) 21:58:06.93

>MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで

逆に、MFCやFormsと比べてもその違いを意識することが少ないと思うが。
トップレベルの要素が<Window>かそうじゃないかの違いくらいしかないし。

**デフォルトの名無しさん** · 2021/08/24(火) 22:00:09.91

うん、あんまり関係ないね
むしろマルチページアプリをコードビハインドを最小にする純粋MVVMで作ろうとすると苦労する

**デフォルトの名無しさん** · 2021/08/24(火) 22:01:39.27

>>689
あなたが苦労して作ったのは大半が MVVM 部分じゃなくて
MVVM + α の α の部分

**デフォルトの名無しさん** · 2021/08/25(水) 03:57:42.90

VMのプロパティとXAMLのプロパティ(Text="Hello World"のTextがプロパティ)をバインディングして組んでいくのがWPFのMVVM
オブジェクト指向がどうとか難しいこと考えなくていい

**デフォルトの名無しさん** · 2021/08/25(水) 07:05:02.51

個人ツール作るだけだと設計が自由でDIで困るような事態にならないので
何もわからない状態のときに、よく見るPrismって何だとか必須なのかとか思って調べてた時間が無駄だった
入門者がMVVMを理解しようとする上で邪魔な情報が多い
今のところ手間削減のために使ってみたいと感じさせてくれるものはReactivePropertyだな

**デフォルトの名無しさん** · 2021/08/25(水) 07:50:46.77

とにかく楽してMVVMしたい人向けならCaliburn.Micro一択

**デフォルトの名無しさん** · 2021/08/25(水) 16:32:19.70

>>696
caliburnはもう死んだだろ

**デフォルトの名無しさん** · 2021/08/25(水) 16:40:02.69

>>694
自分それだわ
バインドバインドぉ！mvvm？こんなのでいいの？動くからおｋ

**デフォルトの名無しさん** · 2021/08/25(水) 16:54:38.02

ReactivePropertyでVM作るのパズル組んでるみたいで楽しい

**デフォルトの名無しさん** · 2021/08/25(水) 17:57:25.18

viewのイベントを全部vmで拾えれば楽なのに
コードビハインドからvmのコマンドつかったら疎結合ガーとか面倒くさい

**デフォルトの名無しさん** · 2021/08/25(水) 19:13:09.36

疎結合おじさん

笑

**デフォルトの名無しさん** · 2021/08/25(水) 19:17:59.52

bland用のframeworkを
mvvmと称して流布した？？だれ？(･･;)
の罪は重いな

**デフォルトの名無しさん** · 2021/08/25(水) 19:48:43.46

MVVMでイベントが使いたいときはMicrosoft.Xaml.Behaviorsを使おう
これ公式WPF拡張パッチみたいなもんだよね

**デフォルトの名無しさん** · 2021/08/25(水) 20:24:15.90

>>699
慣れたらReactivePropertyは手放せない罠
Prismはそれほどでもない

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

ReactivePropertyはナシだな
個人作成のは業務で使えんわ
Prismもサードパーティ扱いだからギリNG

**デフォルトの名無しさん** · 2021/08/25(水) 21:21:12.91

ReactivePropertyやPrism相当のものをMicrosoftが用意しないのがダメすぎる。
ライブラリでもプラットフォームでも各自で勝手にやってくれがひどすぎる。

**デフォルトの名無しさん** · 2021/08/25(水) 21:25:29.69

っ Microsoft.Toolkit.Mvvm (MVVM Toolkit)

**デフォルトの名無しさん** · 2021/08/25(水) 21:45:37.63

これ来るの遅すぎた
名前空間にMicrosoftが付いてればどこの現場でも文句言われずに使えるのに

**デフォルトの名無しさん** · 2021/08/25(水) 21:47:59.78

>>705
多くのオープンソースライブラリが使えなくて大変な職場だねー

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

まあガチガチな所はそうでしょう
遅れてるとしか思わんが

**デフォルトの名無しさん** · 2021/08/25(水) 22:12:40.48

リスクがあるのは事実だからねえ
JSON.NETの作者に悪意があれば明日にも.NETは崩壊するんだよ

**デフォルトの名無しさん** · 2021/08/25(水) 22:16:18.43

>>711
気になるならSystem.Text.Jsonに移行すればいいんじゃないの？

**デフォルトの名無しさん** · 2021/08/25(水) 22:21:02.62

Json.NETはMITライセンスでソースが公開されているからどうとでもなるような

**デフォルトの名無しさん** · 2021/08/25(水) 22:23:12.71

ReactivePropertyもMITライセンスだね

**デフォルトの名無しさん** · 2021/08/25(水) 22:43:32.24

そんなおいらはLitJSON
ただし日本語の扱いにちょいと問題あって自分で直す必要あるんよ

**デフォルトの名無しさん** · 2021/08/25(水) 23:13:06.54

ReactivePropertyってコレクションと双方向バインドできないよね？

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

できますん

**デフォルトの名無しさん** · 2021/08/27(金) 11:29:58.61

MVVMスレが過疎ってるんでこちらで質問させてください。（>>8 その通りです）

Microsoft.Toolkit.Mvvmは、Prismなんかの外部のMVVMフレームワークに対抗して、Microsoft内で作ったMVVMフレームワーク、という認識で合っていますか？
Prismの使い方を知らないんですが、これからはMicrosoft.Toolkit.Mvvmを勉強すればいいですか？

**デフォルトの名無しさん** · 2021/08/27(金) 12:35:53.57

コミュニティツールキットの一部だけど、MS公式と考えていいと思う。
自分の使いたい機能だけピックアップして使えるし、将来性もあるし、軽量だからお勧め。

**デフォルトの名無しさん** · 2021/08/27(金) 12:47:47.66

wpf と同時期に Bland っていうデザイナーアプリが同時期にリリースされていて

wpf ： dotNet標準ライブラリ（プレーンな mvvm 機能のみ）
Bland(デザイナー) ： Bland SDK（mvvmを拡張してドラッグ＆ドロップでUIを設計出来る機能を追加）

ってすみ分けだったんだよ
dotNet標準ライブラリにはプレーンな mvvm 機能のみしか導入しないという意志に思えた
そもそも wpf ＝ mvvm 必須でもないし、
以前のFormsアプリのようにイベントハンドラー（コードビハインド）でも実装出来る

Bland SDK は Bland(デザイナー)を購入しなくてもダウンロード出来たし、
配布も自由だったから、
必要ならdotNet標準ライブラリと Bland SDKを組み合わせて使えって感じ

wpfの登場時からずっと追っかけてる俺からすると、
（wpf → Xamarin → Vue.js → React で Xaml系列は数年前に捨てた）

Bland SDK → Microsoft.Toolkit.Mvvm

に見える（Bland SDK は終了）
標準ライブラリに入るものではなく、
これらの機能はあくまでオプション扱いという事かな

**デフォルトの名無しさん** · 2021/08/27(金) 12:49:05.65

Prismは元々MSが作ったサンプルコード集で、MSがメンテを終了しコミュニティに移管された
まず確実にMicrosoft.Toolkit.Mvvmも同じ運命を辿る

**デフォルトの名無しさん** · 2021/08/27(金) 13:04:11.97

>>720
Blendでしょ

**デフォルトの名無しさん** · 2021/08/27(金) 13:48:17.67

>>722
(;´Д｀)

**デフォルトの名無しさん** · 2021/08/27(金) 15:03:57.58

皆さん、ありがとうございます。

>>719
一応、MS公式と考えてもいいんですね。
他のと比較すると軽量らしいですね。

>>720
なるほど、勉強になります。
ちなみに、そのBlendのドラッグ＆ドロップでUIを設計出来る機能は
Microsoft.Toolkit.Mvvmに引き継がれていそうですか？

>>721
へぇ、Prismも元々はMS製だったんですね。
それなら標準に入れてほしかったですね…。
同じ運命を辿るなら将来性はありますね。
勉強してみます。

**デフォルトの名無しさん** · 2021/08/27(金) 17:11:23.78

>>724
VS 使わなくなって長いからわからんね
VS 使えれば、Blendもライセンス的に付属していたとい思うので、
試してくださいな

**デフォルトの名無しさん** · 2021/08/27(金) 17:18:03.70

デスクトップアプリとウェブアプリ一緒にしてるあたり理解度低そうだな

**デフォルトの名無しさん** · 2021/08/27(金) 17:21:57.98

そんなあなたにElectron！

**デフォルトの名無しさん** · 2021/08/27(金) 18:22:27.64

Electronしたいけど
作り方がよくわからん・・・

**デフォルトの名無しさん** · 2021/08/27(金) 19:16:29.04

Blendはそのうち消えるだろ。
覚える必要なし。

Electronは1アプリごとに新しくブラウザを追加インストールするようなアホアホマンだからやめとけ。

**デフォルトの名無しさん** · 2021/08/27(金) 19:26:17.01

JavaアプリケーションとJavaアプレットは同一で作れたんじゃ

**デフォルトの名無しさん** · 2021/08/27(金) 19:36:53.91

>>725
BlendはVSに抱き合わせで入っていたんですが、速攻で消しました（笑）。
Microsoft.Toolkit.Mvvmでできるか試してみます。

**デフォルトの名無しさん** · 2021/08/27(金) 19:39:16.57

Microsoft.Toolkit.Mvvmを覚えるには、今の所Windows Template StudioというVSの拡張を入れてから
WInUI3かWpfの雛形を自動生成して、そのコードをMSのドキュメント見ながら学習した
ライブラリの中でもMessengerは便利でお薦め

**デフォルトの名無しさん** · 2021/08/27(金) 22:23:27.21

>>728
そんなに難しくないですよー－
ＵＩ/ＵＸに凝りたいならWebの数多あるUIライブラリーが使えるのでおすすめ
一応、Web系はなんでも動く、React, Vueに
ASP.NET Razorとかでもクライアントアプリ作れます

ローカルリソースにあんまアクセスしななら、
PWAとかでもデスクトップアプリ作れますよー－
OS問わずマルチプラットフォームで動きます

**デフォルトの名無しさん** · 2021/08/27(金) 22:29:33.81

そういえば、Messengerパターンって自分が
いろいろ方向性を変えたきっかけでしたね

**デフォルトの名無しさん** · 2021/08/27(金) 23:24:12.33

>>733
Electronで
ユニバーサルスタンドアロンデスクトップアプリケーションの作成方法
Win10pro64bit環境で具体的手順を誘導お流いします

**デフォルトの名無しさん** · 2021/08/27(金) 23:50:29.03

早くにVSからVS Codeに脱却する事をお勧めするが
（いつまでたってもオープンソース世界に行けなくなるので）
手っ取り早くVS使って、派生.NET版のElectron.NETこのあたりで入門できへん？
Blazor使うやつと、ASP.NET MVC Razor のやつ C#で書けるからやりやすいでしょ
https://qiita.com/minoura_a/items/6361a213fdb86343c441
https://qiita.com/nqdior/items/d21d67624d893225762c

**デフォルトの名無しさん** · 2021/08/28(土) 00:01:20.25

>>736
サンクスや鳥会えず見てハロワで基礎かしらねば如何もです

**デフォルトの名無しさん** · 2021/08/28(土) 00:09:05.90

>>737
最初のはBlazorだからデバック面倒なのでやめといたほうが良いね

ASP.NET CORE MVC の方が良いでしょ
動けば、ローカルリソースを使う部分以外のUI的なのは普通のWebアプリと同じ

一応、Electron.NETは派生なので、元のElectronとは少し違う、似てるけど、
.NETな人が雰囲気つかむ目的なら最適かな

**デフォルトの名無しさん** · 2021/08/28(土) 00:15:46.06

記事のリンク先にあった、こっちのが素のElectonだ
https://qiita.com/nqdior/items/091200c9f01e8827fdbd

この場合、ローカルアクセス部分をＣ＃で書きたいなら、
Edge.js という便利なのがある
https://github.com/agracio/edge-js
これは js <-> C# ブリッジだ！

では、貴殿の検討を祈る！

**デフォルトの名無しさん** · 2021/08/28(土) 00:20:01.51

>>738
ASPとか素人なのでLinuxのコマンドみたいなのはよくわからない
Windowsの黒い画面にコピればいいのかな？
エラーの嵐これは場違いなようだワ出直してくらぁ
でもあーざーした

**デフォルトの名無しさん** · 2021/08/28(土) 01:37:37.38

スレチと自分語りしかいなくなってしまったなｗ

**デフォルトの名無しさん** · 2021/08/28(土) 02:57:21.18

>>732
Windows Template Studio、さっそくインストールして試してみました。
いいですね。Navigation Paneのテンプレートもすぐに試せました。

でも、その参考にしたサイトがPrism推しで、
良いチュートリアルがあるみたいなんで
Prismでもいいのかなとまだ少し迷っています。
ああいうサイトがもう少し前にあったらPrismやってたんですけどね。

**デフォルトの名無しさん** · 2021/08/28(土) 06:38:54.70

信者がｷﾓｲからElectronはやめておこうっと…

**デフォルトの名無しさん** · 2021/08/28(土) 11:56:24.12

Prismは複雑怪奇だったんだが、Ver７で破壊的更新をやって前との互換性は失ったけど
機能は整理されて格段に使いやすくなっているんだよな
昔触った人が二度と使いたくないと思う気持ちはわかるし、
互換性を犠牲にしたバージョンアップで他所に移った人もいるだろうが
今のやつは言うほど酷いものじゃない

**デフォルトの名無しさん** · 2021/08/28(土) 20:09:03.92

prismは途中から路線変更してフレームワーク的なライブラリみたいなのになったところで切った

**デフォルトの名無しさん** · 2021/08/28(土) 21:00:05.63

なんで？

**デフォルトの名無しさん** · 2021/08/28(土) 21:04:04.97

Webview2ってClearScriptみたいにJSのFunctionオブジェクトをデリゲートに変換できないのかな？
UIだけReact、それ以外の層を.NETで実装してて詰まった
素直にmessage使うしかない？

**デフォルトの名無しさん** · 2021/08/28(土) 21:57:39.12

>>745
切らないでも便利なライブラリだけ使えばよくね？

**デフォルトの名無しさん** · 2021/08/28(土) 22:09:34.58

>>720
BlendはXAMLの拡張だしMicrosoft.Toolkit.Mvvmと比べるようなものではないだろ
XAML=MVVMだと思っているのか

**デフォルトの名無しさん** · 2021/08/28(土) 22:34:13.14

>>747
素直にElection.NETじゃね？

**デフォルトの名無しさん** · 2021/08/29(日) 08:10:20.00

>>748
だからPrismみたいに図体の大きい融通の利かないのじゃなくて
他の便利なライブラリに移ったんだろ

**デフォルトの名無しさん** · 2021/08/29(日) 12:47:48.75

>>751
DLLのサイズ確認したけど
Prism.dll : 90KB
Microsoft.Toolkit.Mvvm.dll :73KB
大してサイズ変わらないと思う
Prism.Coreだけnugetしたら特別図体が大きいわけじゃないね

**デフォルトの名無しさん** · 2021/08/29(日) 12:55:35.31

本質のわからないの登場！

**デフォルトの名無しさん** · 2021/08/29(日) 14:40:31.76

もう頑張らなくていいのよ。
Prismはオワコンだもの。

**デフォルトの名無しさん** · 2021/08/29(日) 15:02:04.81

prism使ってるけどwindow開いていってるわ・・・

**デフォルトの名無しさん** · 2021/08/29(日) 15:25:31.85

本質というか、周回遅れすぎる感じ
すでに表彰式終って解散してるのに、これからマラソン始める人いるよ

**デフォルトの名無しさん** · 2021/08/29(日) 15:28:39.38

WPFの周辺技術にオワコンでないものなんて存在しないんだから好きなの使えばいいよ

**デフォルトの名無しさん** · 2021/08/29(日) 15:35:30.15

WPFとUWPオワコンなの気づかずにまた2つを合体させようと頑張ってるMSってなんか哀れだよね

**デフォルトの名無しさん** · 2021/08/29(日) 16:12:15.50

でWinUI3は使い物になるのかねエロい人

**デフォルトの名無しさん** · 2021/08/29(日) 19:14:54.89

WPFとかUWPとか関係ない
Windowsがオワコンなだけ
WPF、UWPに変わる優れたシングル環境のフレームワーク出てきてもwindowsアプリ増えないから

flutterなどのクロスプラットフォームに寄生して、ついでにWindows向けをビルドしてもらうしかない

**デフォルトの名無しさん** · 2021/08/29(日) 19:20:15.34

まぁ、win11でandroidアプリの実行環境が用意されるから、もうこうやってアプリ増やすしかない
LOBとかならまだしも一般向けのアプリのwindows専用に作る人なんてわずかだろ

**デフォルトの名無しさん** · 2021/08/29(日) 21:53:04.96

そもそもソフトウェア自身が儲けにくくなってきてる気がするよ。
検索エンジンで儲けた金で大量のプログラマに作らせたソフトを無料で配布される
ようになってしまったり、MS Officeみたいに独占禁止法違反してそれ以外のものが
入っていく余地がほとんど無くなったり。作っても作っても、MS Wordなどに
真似されて実装されるから自分が作ったものがまともに売れることは無い。

**デフォルトの名無しさん** · 2021/08/29(日) 22:37:23.02

Wordの新機能なんて興味ないから全く知らないんだが
なんかひどいことしてんの？

**デフォルトの名無しさん** · 2021/08/29(日) 22:42:34.76

今時Windowsのソフト開発なんてほとんどがB2Bでしょう

**デフォルトの名無しさん** · 2021/08/29(日) 23:17:01.60

業務システムはほぼWebになったよ

**デフォルトの名無しさん** · 2021/08/30(月) 00:08:17.14

C#でWeb系やるとしたらASP.NETしか無いですか？
C#とJavaScriptとの組み合わせも可能ですか？
それをやるんだったらNode.jsとの組み合わせの方が楽ですか？

**デフォルトの名無しさん** · 2021/08/30(月) 01:57:25.98

>>765
そういう会社もあるかもしれんけど、たとえば奉行なんか使っている大多数の企業はなってない

**デフォルトの名無しさん** · 2021/08/30(月) 02:20:34.86

>>767
大手、中堅どころの企業なら
システム開発はほとんどWebだよ

業界の人なら営業が持ってる案件表見てみるがいい
もしクライアントアプリがそこに有るとすれば
スマホ位しかない

大体運用やメンテナンスし辛いクライアントアプリとか
情室が嫌がる

**デフォルトの名無しさん** · 2021/08/30(月) 02:24:16.67

業務系のエンジニアなら
10年以上前からその流れになってたから
殆どのエンジニアはWebに流れたよ
仕事先細りして食ってけないから

**デフォルトの名無しさん** · 2021/08/30(月) 06:08:05.56

C#はクロスプラットゲーム向けと、
内部GUI/CUIツール向きかな。

**デフォルトの名無しさん** · 2021/08/30(月) 06:20:07.92

デスクトップアプリからWebに移ってまたデスクトップに回帰する流れもあるところはあるけどな

**デフォルトの名無しさん** · 2021/08/30(月) 06:40:21.81

WebやるならVueがWPFに似てるから良さそうだな

**デフォルトの名無しさん** · 2021/08/30(月) 09:03:38.02

業務系の開発現場にいたらわかるけど、
（自分は独立してて、あちこちの開発現場に出入りしてた）
10年以上前から Web開発者 > クライアントアプリ開発者になってた
今じゃ、クライアントアプリの開発なんて保守しかないし
会議にも呼ばれなくなって立ち位置がどんどん低くなってんだよ
（俺も専門は元々クライアント側だったけど、web系に完全シフトした
WPFもXamarinももう依頼されても仕事受けない）

それでも、サーバーサイドはまだC#は残ってる
ASP.NETの新規開発はまだあるし
ただWeb開発担当者の口癖は、
３年位前は次はAngularで、
２年位前は次はVue.jsで、
１年位前から絶対React！！になってる笑
世界的に見ても、React一強の情勢になってしまったからね

あと、クライアントアプリの新規開発はFlutter激増してる
これはデスクトップからスマホにWebアプリまで作れる
しかも新機能のリリースがめちゃくちゃ早い
笑うぐらいに死角が無いし、開発者ならすぐ仕事みつかる

**デフォルトの名無しさん** · 2021/08/30(月) 09:42:39.49

ReactかSvelteかな
MVVMの本来の目的を意識低く実現していて、ああ、MVVMで色々変なクラス捏ねくり回してやろうとしてたのは結局こんなくだらないことだったんだなあと
Vueは所詮MVVMなのでアーキテクチャ的にはあまり学びはないかな

**デフォルトの名無しさん** · 2021/08/30(月) 10:11:13.12

>>774
“MVVMで色々変なクラス捏ねくり回してやろうとしてたのは”
過剰なまでの疎結合だよ
意味的にもMVVMとはちと違う指向