【本命】Blazor スレ1【真打】

**デフォルトの名無しさん** · 2020/07/20(月) 23:36:36.67

混沌を極めるWebアプリケーション界隈に現れた一筋の光明
型無し言語 JavaScript の悪夢を打ち払い
林立するエコシステムの亡霊を退散
アプリケーション開発者の希望となるMVVMを引っ提げて登場した真のSPA開発環境

Blazorを語る者よ、集え！

ASP.NET Core Blazor の概要
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-3.1

**デフォルトの名無しさん** · 2020/09/21(月) 12:19:35.43

**デフォルトの名無しさん** · 2020/09/21(月) 12:30:35.11

>>550
速度も問題ないね
結局、体感でサクサクならベンチマークとかどうでもいいんだよな
開発生産性が高いメリットを享受できる

ハード性能あがればさらにJSで書く人は減るだろう

**デフォルトの名無しさん** · 2020/09/21(月) 13:28:01.42

>>550
502 Bad Gateway
が出て起動すらしない。

**デフォルトの名無しさん** · 2020/09/21(月) 14:05:36.06

>>552
viewの処理のほとんどは
Chart.jsなんじゃないの？
99%ぐらい。

**デフォルトの名無しさん** · 2020/09/21(月) 14:30:28.63

そうだね
フロントエンドのパフォーマンス的な観点で言えば、100%普通のJSで動いていると言って差し支えない
そもそもWebAssemblyじゃなくてBlazor Serverだしな

**デフォルトの名無しさん** · 2020/09/21(月) 14:38:45.50

Chart.js使った時点で、
Blazorの出番ないし
最初から全部JSで書いたほうが
楽だし、簡単だよね。

クライアントサイドでC#で動かしたいライブラリーが無かったら
何の価値が有るんだろう。

**デフォルトの名無しさん** · 2020/09/21(月) 17:14:00.32

Blazor Serverだったのか
それなら少人数なら快適に動いて当たり前か

Blazor Serverはスケーラビリティはないらしいね
ぜんぶserver sideでやるから当たり前だけど。
不特定多数向けサービスならBlazor Serverは選ばないほうがいいと思う。
アクセス数が予測できるイントラ利用向けと解説されてた

アクセス多い場合はWebAssemblyとかHybridとかnative appとかほかの技術使う

**デフォルトの名無しさん** · 2020/09/21(月) 17:20:21.47

>>557
はぁっ？

**デフォルトの名無しさん** · 2020/09/21(月) 17:28:12.77

>>558
なんなのその頭悪いレス？
言いたいことあったらはっきりかけアホ

**デフォルトの名無しさん** · 2020/09/21(月) 19:27:13.31

WebFormsで作られた業務システムの移行先に考えてるんだけど、
何でもかんでもblazorで作ると開発コストがかさみそうで…。

複雑な画面構成の機能はBlazorで作って
DBの値を更新するだけの単純な機能はMVCのスキャフォールド機能使って作るみたいなことはできるんだろうか。

いいプロジェクトの構成が思いつかない。

**デフォルトの名無しさん** · 2020/09/21(月) 20:03:05.36

MVCか Blazor Server でいいんちゃうの
Blazor でも WebAssembly使うとプロジェクトも二つになるし
考えないといけないことも増えるかな

SPAにしたくってでもJavaScript/TypeScript極力使いたくないならBlazorかな

**デフォルトの名無しさん** · 2020/09/21(月) 21:52:08.52

>>559
全部サーバーサイドだとスケーラビリティがない

これに
は？
以外どんなレスが付くと思った？

**デフォルトの名無しさん** · 2020/09/21(月) 22:47:24.40

サーバーサイドのは
signalRでクライアントと
Websocketでセッションを張る。
この時点で社内システム程度の運用が限界。

**デフォルトの名無しさん** · 2020/09/21(月) 23:03:25.83

>>562
558のアホか？
初心者のくせに上から目線、ウザすぎ
反論、質問があるなら伝わるように具体的にかけ

俺の見解じゃなくスペシャリストの見解だ
断言する。Blazor Serverはスケーラビリティはない

ServerのCPUとRAMのリソースを最大限に浪費する
セッションも最大限に使う
Serverの処理が重いというのにさらに
SignalRはリアルタイムなJSレスポンスを要求してくる
認証とか絡むと単純にサーバー増やしても解決できない
スケールアウトは極めて困難と言われている

これが理解できないのはサーバー増やせばスケールアウトすると
考えてるような初心者かバカだ

**デフォルトの名無しさん** · 2020/09/21(月) 23:13:14.88

>>563
SignalRがリアルタイムの処理が要求してくるからな
そこで破綻する

**デフォルトの名無しさん** · 2020/09/21(月) 23:38:03.42

リアルタイムリアルタイムってバカの一つ覚えわろた

株価の情報配信するわけでもないだろうに

**デフォルトの名無しさん** · 2020/09/22(火) 00:11:30.38

>>566
何も表示しない画面でも
Websocketのセッションを張るんだよ。
不得意多数の要件には使えない。

なんでらこんな不安なシステムを考案したか
理解できない。

が

多分Webassembly版が出せない時代の
お茶濁しだろうけどね。

**デフォルトの名無しさん** · 2020/09/22(火) 00:14:57.89

あ！

Webassemblyが動作しない処理系にも
同一コードが使えるメリットはある。

いらんけど。ね。

**デフォルトの名無しさん** · 2020/09/22(火) 00:24:35.49

>>567
566はろくにコード書けない上に上からのアホだから
ほとんどレスを理解できてないぞ

Blazor Serverの数少ないメリットはセキュリティ。
コードをclientに極力見せずに作れる。
スケーラビリティを犠牲にしてでもセキュリティが
重要な社内用途とかなら使いどころになりうる

**デフォルトの名無しさん** · 2020/09/22(火) 00:42:48.24

>>567
うん、セッション張るのは Signal-r使ったことあるからわかるよ
っていう今もある業務システムで使ってるわ

ただ、リアルタイムが云々っていうのちょっとね

あと不特定多数って言ってもそんなにたくさんの人がずっと接続し続けるものもあればそうでないものもあるからね

結局どういうアプリ次第なんだよ

**デフォルトの名無しさん** · 2020/09/22(火) 01:17:58.77

>>569
ソース漏は
Webassemblyなら大丈夫でね？
なのでサーバーサイドの使い道は
殆ど思いつかん。

**デフォルトの名無しさん** · 2020/09/22(火) 01:29:18.19

デイトラで有名な、東京フリーランスのとだこうきの動画

0から手を動かして作るRailsチャットアプリ【チュートリアル】
https://www.youtube.com/watch?v=WCsgcp5dg7M

Ruby on Rails で、Web Socket

**デフォルトの名無しさん** · 2020/09/22(火) 01:40:46.22

>>564
あ、はい

**デフォルトの名無しさん** · 2020/09/22(火) 08:14:13.81

>>561
ありがとう
あなたのレス以降Blazor Serverがディスられてて複雑な心境。。

しかし、イントラネット内で千人くらいしか使わないような業務システムならBlazor Serverがベターな気がする。

不特定多数が使うウェブアプリならWebAssemblyがベターなんでしょう。

**デフォルトの名無しさん** · 2020/09/22(火) 09:07:26.70

>>574
同時使用ユーザー数次第だが1000人って規模としては大きめ
基幹業務のシステム？

あとあとパフォーマンス問題でたら無能扱いされるよ
スケールできない技術でやって破綻したら最悪、全部つくりなおし
高価なサーバーの購入が必要になる可能性もある。
責任とれるの？

>>553　で
502 Bad Gateway
でてる人いただろ、これパフォーマンス不足が原因の可能性ある

俺はパフォーマンスでない技術だけは選ばないわ
Blazor Serverでなければならない理由もないのに選ぶ理由がわからん

**デフォルトの名無しさん** · 2020/09/22(火) 09:19:17.86

責任てw
呑み屋で見ず知らずのオヤジに説教受けているみたいな

**デフォルトの名無しさん** · 2020/09/22(火) 09:31:32.20

サラリーマンなら特に重要だろ
プロジェクト失敗したら上流設計やったやつらは
完全に無能扱いされるし
社員からもあいつが上流設計したせいでって陰口叩かれるわｗ

**デフォルトの名無しさん** · 2020/09/22(火) 10:42:28.47

>>577
おっしゃるとおりパフォーマンス問題が出たら、後々何言われるか分からないのがこの業界の常でございます。

ただ機能数が百を超える業務システムを全部が全部blazorで作るわけではない。
特定の機能だけblazorで作りたい…

しかしそんなにパフォーマンスでないもんなんかね

https://devblogs.microsoft.com/aspnet/blazor-server-in-net-core-3-0-scenarios-and-performance/
これ見てると
a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency.

とあるけどこれまさかあのクリックするたびにカウントアップしますよアプリで試してるんだろうか…
複雑な画面でやるとダメダメなんだろうか…

**デフォルトの名無しさん** · 2020/09/22(火) 11:37:42.85

WebSocketのセッションが5000までいけるってことなんじゃないの
VPSなんかだとサーバの設定もあるから
きちんと設定できないとすぐに制限いっぱいになっちゃうんでしょ

どこにサーバーおくかも考えて決めたら

**デフォルトの名無しさん** · 2020/09/22(火) 14:43:37.98

ローカルの環境でIIS Express使ってテストしたら
5000コネクション余裕で張れたわ

**デフォルトの名無しさん** · 2020/09/22(火) 15:17:57.43

SSRがスケールしないって嘘ついてまでBlazorを貶めたいのかねぇ

**デフォルトの名無しさん** · 2020/09/22(火) 16:27:39.02

>>580
scalabilityについては多くの人があげてるけど一例
Blazor Serverの長所短所
Blazor server-side vs client-side (WebAssembly) | What should you choose?
https://youtu.be/HFvPKmS2gig?t=588

localでセッションだけ張れても安心ではないだろう
Blazor ServerはRAMやCPUのリソースも多く使う。
処理速度も遅くなる

あとWAN経由でもアクセスするならネットワークのパフォーマンスも問題になる
結局、パフォーマンス絡みは稼働後に問題が発覚することが大半
採用するなら徹底的にパフォーマンスは事前検証したほうがいい
失敗したら確実に無能の烙印おされる

**デフォルトの名無しさん** · 2020/09/22(火) 17:07:46.37

サーバでテンプレートエンジンを動かして、HTMLを生成
必要なところだけ部分的に、AJAXで更新

結局のところ、それだけでよかったんだ
SPAもSSRも最初から失敗だった

**デフォルトの名無しさん** · 2020/09/22(火) 23:24:11.38

https://docs.microsoft.com/ja-jp/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1#blazor-server
> 多くのユーザーがいるアプリで、スケーラビリティが課題になります。

**デフォルトの名無しさん** · 2020/09/22(火) 23:40:57.68

AWS Elastic Beanstalk は、次の言語と開発スタックをサポートしています

Apache Tomcat for Java アプリケーション
Apache HTTP Server for PHP アプリケーション
Apache HTTP Server for Python アプリケーション

Nginx or Apache HTTP Server for Node.js アプリケーション
Passenger or Puma for Ruby アプリケーション

Microsoft IIS 7.5, 8.0, and 8.5 for .NET アプリケーション
Java SE

Docker
Go

**デフォルトの名無しさん** · 2020/09/22(火) 23:48:23.46

だからその
多くのユーザーって何人の話なんだよ
10万人か100万人か

**デフォルトの名無しさん** · 2020/09/23(水) 00:08:25.99

>>584
個人的にはこっちのほうが嫌だな

SignalR 接続に "スティッキーセッション" を実装する必要があります。

負荷分散装置やらプロキシサーバーやらでいつも苦労する

**デフォルトの名無しさん** · 2020/09/23(水) 02:33:18.98

結論的だけど、
Blazorてjsすら使えないエンジニアの為の
救世主ぐらいしか価値を見いだせない。

Blazorだって学習コストかかるのに
その分JS学んだ方が将来的な
メリットは計り知れないと思うけど。

**デフォルトの名無しさん** · 2020/09/23(水) 12:28:24.15

>>581
アンチと決めつけうざい
じぶんはずっと前からからC#とASP.net推してきてる
スケールしないといってるのはBlazor Serverだ。
Blazor WebAssemblyについてはスケールしないといっていない

>>584にも
MSのサイトにスケーラビリティの欠点かいてあっただろ
前にはなかったが追加された

**デフォルトの名無しさん** · 2020/09/23(水) 12:33:56.41

>>588
JSのほうが将来性ないのになにいってんだ
Wasmが普及したらメインの開発言語でJSを選ぶ人はいなくなる

JSは開発生産性が低いしnode.jsなどserver sideで使っても遅い

Blazor使う層はC#が使える
JSは使えないのではなく、生産性が低いから使いたくないのだ

**デフォルトの名無しさん** · 2020/09/23(水) 13:46:42.94

JavaScriptとセキュリティーについては、紙教材ベースでは学習してはいるけど・・・・
どっかで実務経験を積まないことには、素人サービスであっても実戦投入なんて危なくてできないな

**デフォルトの名無しさん** · 2020/09/23(水) 17:06:15.80

>>590
開発生産性は
VS code + Hot Relode の
vuejsとかreactの方が高いですよ。
言語もTypescriptとか使えば死角がなくなります。

**デフォルトの名無しさん** · 2020/09/23(水) 17:22:32.14

>>592
ありえない
reactはframeworkじゃないし関係ない
静的言語は速度も生産性もC#に勝てない

C#やasp.netを知らない人の意見とすぐわかる
必要なコードの量が全く違う

**デフォルトの名無しさん** · 2020/09/23(水) 17:27:33.88

Javaの方が早く死にかけてるのに驚いてる
古くからのC#erですよ。
ASP.NETの前のASPのベータ版から親しんでる
爺です。

**デフォルトの名無しさん** · 2020/09/23(水) 18:44:41.10

>>584
Blazor WebAssemblyと比較しての欠点でしょ
シンクライアントとファットクライアントを比べたら当然のことが書いてあるだけ

**デフォルトの名無しさん** · 2020/09/24(木) 08:05:11.98

技術選定するにあたって、
Blazorの対抗馬としてReactやらVueやら最近流行りのフレームワークは当然候補に上がってくる。

しかしこの手の技術、実際手を動かして作ってみたことがない…
本当のところ生産性ってどうなんだろう。
両方使いこなせてる人に生産性の違いを教えてもらいたい。

以前なんかのブログに、
TypeScriptは型が使えるんですよ。するとIDEでコード補完やリファクタリング機能が使えるんですよ！これは便利！
と書いてあるのを見た。
実はWeb系の人たちってこれまでものすごい苦行を強いられてきていたのでは…

**デフォルトの名無しさん** · 2020/09/24(木) 08:47:14.39

>>596
server-sideの生産性はasp.net coreが格段に上
UI component作るだけならJS/C# どちらの言語に慣れているかで
変わるかもしれない。

流行ってるかどうかではなく、優れているかどうか、
自分のスキル、好みで決めればいいよ
PHPみたいにそこそこ流行っていてもクソみたいな言語もある

**デフォルトの名無しさん** · 2020/09/24(木) 09:31:02.38

>>597
チームで開発してるからなかなか自分の好みだけでは決めれなくて…

Blazorつかいます！ってなったら
そんなのよりVueを使いたまえとか言ってくる偉い人が必ず出てくる。
若い子も流行りのtsやReact、Vueをマスターしたいってなると思う。

そのとき、君たちの憧れの言語やフレームワークはこんな苦行を強いられるのですよと言えるようにしておきたい。

**デフォルトの名無しさん** · 2020/09/24(木) 10:04:58.46

>>598
流行りで決めるほうがよっぽど論理的でないだろう

server-sideのbenchmark見てみりゃわかる
node.js系はasp.net coreよりかなり遅い。
それだけでJS系frameworkを使わない理由になる。

同じ言語C#でclient-sideも開発できればコストも削減できる。
Vueなんて個人ベースで作ってるものだろ
長期サポートされないしnode系だから速度も遅い。

**デフォルトの名無しさん** · 2020/09/24(木) 10:15:36.19

流行ってるかどうかでいったら普及率ナンバーワンの
web frameworkはWordPressなわけだけど、
本格的なweb appをそんなゴミで開発しようとはならないでしょ。
シェアで技術を選ぶのは完全に間違いってこと

**デフォルトの名無しさん** · 2020/09/24(木) 11:31:25.30

WebサイトとWebアプリの違い

**デフォルトの名無しさん** · 2020/09/24(木) 12:43:26.88

JavaScript は改良が続くんだろうし
いつかTypeScriptとの違いもなくなっちゃうのかもしれんね

そうなったらクライアントサイドがJavascriptでもいいのかもしれない

**デフォルトの名無しさん** · 2020/09/24(木) 13:12:22.54

>>602
JSは互換性重視だから大幅には変わらない。
wasm普及したらJSの役割はおしまいだろ

PCとSPで動くnative appを開発できるツールが
でてきてweb appが下火になる未来も来ると思うわ
AppleもMAC向けARM系独自プロセッサ開発する。
最後はcross platform対応のnative appに向かう

**デフォルトの名無しさん** · 2020/09/24(木) 18:26:57.96

中途半端Bootstrapより、なんかまともなもんを一つ移植して欲しいな

**デフォルトの名無しさん** · 2020/09/24(木) 19:48:01.41

WebAppは、下火になるとしても、独特の面白さがある。
ビビッドアーミーなんかも、Webからすぐに始められるから、インストール型
のゲームよりも罪悪感が少ないため、ヒットした可能性がある。

**デフォルトの名無しさん** · 2020/09/24(木) 19:51:18.25

>>596
最近までasync/awaitもなかったんやで・・推して知るべし
自分は最近仕事で使ったからReactはギリ推せる
なぜかというとhooksが導入されたり関数コンポーネントが主流になったりで
React周りの記述量が大幅に減ったから
Reduxなんか挫折する人が出るくらい記述量が無駄に多かったらしい
それもRedux-Toolkitでずいぶん楽になったようだ
調べているうちに新旧のコードを見かけるけど
旧Reduxで組んでた人はよく発狂しなかったと感嘆した
まだまだ記述量が減る余地はあると思うから期待したい
BlazorはRedux-Toolkit以上の使いやすい状態管理が提供されれば
仕事でも使ってみたい
ReactとVueは選定するとき迷ったが、サポートしているのが
FaceBookとコミュニティでは巨人の肩に乗るほうがよいと判断した
Augularは構文デザインになぜか吐き気を覚えたので選定から外した

**デフォルトの名無しさん** · 2020/09/24(木) 20:22:47.35

みなさん貴重なご意見ありがとう。

Web系のひとたち、俺たちは最先端のことやってるぜ感出してるけど、
昔のVBAみたいな、あとで誰も手をつけれてないようなシロモノを職人技で苦労しながら作ってるような気がしてて…
そういうのは仕事では使いたくない…

あとBlazorに望むこととしては、
WinFormsやWebFormsみたいに標準のコントロールを充実させてほしい。
DataGridViewやTreeViewが海外のサードパーティ製にしかないのはこれまたお仕事では困る…
ぼちぼちGrapeCityあたりが出してくれそうだが…

**585** · 2020/09/24(木) 21:43:39.63

YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる

この2つ以外は、出てこない

GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった

言語よりも、Docker, Kubernetes, AWS などの、サーバー構築・新規案件を重視する。
上流工程・新規案件の方が、価格交渉力が強いから。
一方、下流工程・保守案件は低価格しかない

>>585
で書いた、AWS Elastic Beanstalk の中で、
Puma for Ruby, Docker, Go を抑えておけばよい

**デフォルトの名無しさん** · 2020/09/24(木) 22:08:01.62

サーバー版Blazorのシステム納品間近
サーバーサイドとクライアントサイドをC#同一ソースコードで記述できるから開発効率高いね

**デフォルトの名無しさん** · 2020/09/24(木) 23:51:59.19

>>609
Blazor ServerのApplication Serverは何台構成？
同時使用ユーザー数の規模はどれくらい？

良い言語C#でclient-server両方かけるっていうメリットは大きい

**デフォルトの名無しさん** · 2020/09/25(金) 10:34:56.50

>>607
web系はアホが多い

過去に失敗した経験に学ばず同じことを繰り返してるし

**デフォルトの名無しさん** · 2020/09/25(金) 12:17:21.21

ウェブ系は雇用の安定感が無いから新しい事やってます感をアピールしないと次がないのよ
だから同じようなことを言い方や見せ方を変えながら繰り返してる

**デフォルトの名無しさん** · 2020/09/25(金) 14:05:33.75

>>607
サードパーティ製コントロールって
JS & CSSのラッパーコントロールですよ。C#の。

なので、コントロール欲しければ、普通の配置して、
JSをC#から interopすればよろし。

**デフォルトの名無しさん** · 2020/09/25(金) 14:43:52.18

俺的にはまず、Blazor Serverside + Blazor Webassemblyの組み合わせで使えるようにして欲しいな
これができないことには、いつまで経ってもJavaScriptから逃げられん
Blazor Serversideでログイン関連等の基本的な部分を作り、Blazor Webassemblyでウィジェットのようなものを作るような、そういう組み合わせができるように改良して欲しい

**デフォルトの名無しさん** · 2020/09/25(金) 16:00:21.21

>>614
？

**デフォルトの名無しさん** · 2020/09/26(土) 18:22:12.35

MS新ﾌﾚｰﾑﾜｰｸBlazor、Lighthouseで23点を叩き出すｗ
https://mevius.5ch.net/test/read.cgi/tech/1596698340/

**デフォルトの名無しさん** · 2020/09/30(水) 02:31:21.68

WebAssemblyとJavaScriptの処理速度を比較してみる
https://qiita.com/mink0212/items/c7fc8d1e7c036b706544

やはりhtml domを突いて画面だしてる現状では意味ないかも...

**デフォルトの名無しさん** · 2020/10/04(日) 06:42:57.11

業務アプリならsilverlightを温めとけばよかったのよ
ria service も廃止してAzure売り出す始末でタチ悪すぎるわ

どうせまた3年でオワコンになり、再開発させられる羽目になるんだよな
wcfとかどうなるんだよ

**デフォルトの名無しさん** · 2020/10/04(日) 13:10:28.51

WCFはまだ現役じゃろ
Remotingは終わったけど

**デフォルトの名無しさん** · 2020/10/04(日) 13:25:48.26

>>619
Remotingは「レガシーとされている」状態ね。

**デフォルトの名無しさん** · 2020/10/04(日) 13:26:23.01

Silverlight はFlashと一緒で消える運命でしょ

Blazorは Server版は既存の記述組み合わせたものだし
WebAssembly もマイクロソフトが単独でやってるわけでもないし
すぐには消えなさそうだけど
それも世の中の技術の進歩とトレンド次第かな

**デフォルトの名無しさん** · 2020/10/04(日) 13:39:56.64

全く性質が違うからねー
Blazorがいつまで続くかはわからないがクライアントサイドC#はずっと残ると思う
Webasm自体が続く限りは

**デフォルトの名無しさん** · 2020/10/04(日) 13:40:59.36

>>619
WCFからgRPCへ乗り換えを勧めているらしいぞ

**デフォルトの名無しさん** · 2020/10/04(日) 14:22:11.82

ASP.NET CoreのRazor Pagesと
ASP.NET CoreのMVCと
Blazor WebAssemblyの使い分けがよくわからない。

ページ単位でURLを持たせたい場合は
Blazor WebAssemblyは使えない？

**デフォルトの名無しさん** · 2020/10/04(日) 14:30:19.90

>>624
使えるよ

**デフォルトの名無しさん** · 2020/10/04(日) 16:06:30.15

ポストバックを多用する昔ながらの単純なウェブアプリならPages
ビューを開いた後にクライアントサイドでゴリ押しする少し複雑なウェブアプリならMVC
MVCでクライアントサイドが管理しきれない規模の高難易度ウェブアプリならBlazor

MVCが一番バランスいい
Blazor、というかSPAにするほど複雑なウェブアプリが滅多にない
SPAはPgadmin、CodeServerみたいなガチめのアプリのための技術

**デフォルトの名無しさん** · 2020/10/04(日) 16:18:17.46

MVCはどっちかというとWeb API向け。UIがあるんならRazor Pagesが無難。

**デフォルトの名無しさん** · 2020/10/04(日) 16:37:36.76

そうかな
テンプレートは1回表示して終わりだからMVCのほうがシンプルでいいと思う
ポストバックするならPagesのほうがやりやすいけどね

**デフォルトの名無しさん** · 2020/10/04(日) 16:55:49.81

uno projectってどうなんだろうか？

**デフォルトの名無しさん** · 2020/10/04(日) 16:57:01.23

>>628
テンプレート？

**デフォルトの名無しさん** · 2020/10/04(日) 16:57:59.06

少し規模が大きくなると、MVCはどこでどのエンドポイントが呼ばれているかカオスになるからね…

**デフォルトの名無しさん** · 2020/10/04(日) 17:04:51.79

https://stackoverflow.com/a/50793220/8778560

**デフォルトの名無しさん** · 2020/10/04(日) 17:05:06.55

これ以上はスレチかな

**デフォルトの名無しさん** · 2020/10/04(日) 21:32:49.31

>>620
MSの言い方は知らんけど.NET Coreで使えないんだからもう終わりでしょ

**デフォルトの名無しさん** · 2020/10/04(日) 23:12:02.56

>>634
.NET Frameworkでは使えるし、Windowsが生きている限りサポートされ続けるから「終わった」は言い過ぎやろ

**デフォルトの名無しさん** · 2020/10/04(日) 23:50:16.30

今、wpfをクライアントとしてサーバーのsqlserverにcrudするには何が主流なの？
wcf？asp.net mvc？

**デフォルトの名無しさん** · 2020/10/05(月) 00:13:15.07

いまだとWeb APIになるんじゃない

**デフォルトの名無しさん** · 2020/10/05(月) 03:23:01.66

>>635
新しく立ち上げるプロジェクトで使用できないなら「終わった」でいい
VB6は終わった技術じゃないというならそれでもいいが

**デフォルトの名無しさん** · 2020/10/05(月) 04:58:38.75

>>638
使用できるでしょ。.NET FrameworkはWindowsのサポート期限と同じなんだから。

**デフォルトの名無しさん** · 2020/10/05(月) 08:49:16.96

>>638
いきなりは終わらないだろ

**デフォルトの名無しさん** · 2020/10/05(月) 19:08:30.24

>>639
言葉足らずですまん
.NET Core で使えない==新しく立ち上げるプロジェクトで使用できない
とすっ飛ばして書いた。
.NET Frameworkの保守で使う新規プロジェクトなら使えるね

**デフォルトの名無しさん** · 2020/10/06(火) 17:17:17.54

Blazorはコンパイル時間が痛いな

**デフォルトの名無しさん** · 2020/10/06(火) 18:02:17.12

>>642
コンパイルなんて数秒で終わるだろ

**デフォルトの名無しさん** · 2020/10/15(木) 21:39:41.60

Blazor WebAssemblyをテンプレートからいろいろいじってみたけど、
もうちょいテンプレートしっかり作ってほしい。
せめてCRUDのテンプレ欲しかったなあ。
あとClient側、trycatchくらい書いとけよと。

あととにかくデバッグがうまくいかない
ctrl+shift+iだったかな、これ押すと一応デバッグできるようになるんだけど、そんなん分かるか！ってかんじ。

**デフォルトの名無しさん** · 2020/10/16(金) 01:17:51.30

>>644
ドキュメント読めよ

**デフォルトの名無しさん** · 2020/10/16(金) 22:21:03.61

>>644
scaffoldなかったっけ？

**デフォルトの名無しさん** · 2020/10/18(日) 16:09:45.98

Blazor使って作られたサービスってある？
調べても使ってみたとかばっかでる

**デフォルトの名無しさん** · 2020/10/18(日) 17:03:18.35

>>647
実際の公開サイトでの統計
https://www.wappalyzer.com/technologies/web-frameworks/
Blazorは670 sitesだから徐々に増えてきてる

あと企業内のシステムでBlazor Server使ってるシステム増えてるはずだが
非公開web appなので上の統計には出てこない。
MSの技術は法人利用多い

しかしまだBlazorではないASP.netのシェアが圧倒的
ほとんどのサイトはSPAである必要がないので
ASP.NET MVCとかRazor Pagesで十分ってことかもしれない

**デフォルトの名無しさん** · 2020/10/18(日) 17:16:32.49

>>648
なるほどねー
たしかにMVCで十分なシーン多いわ

ありがとう助かりました

**デフォルトの名無しさん** · 2020/10/18(日) 19:22:38.17

ユーザー名+パスワードのハッシュの入った既存のデータベースを、Blazorのユーザー認証に使い回す方法ってどっかに紹介されてない？