【本命】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/10/18(日) 21:49:08.25

>>651
ありがとう！これは便利だ！
クッキー発行前に自分のやりたい認証コードを書けば、なんでも使いまわせちゃうぜ！

**デフォルトの名無しさん** · 2020/10/19(月) 11:41:11.48

>>651
そのサイトはいいかんじにまとまってるサンプルがあるね
ブックマークしておいた

**デフォルトの名無しさん** · 2020/10/19(月) 13:14:16.03

俺は逆に、Blazorで登録してもらったユーザー情報で他のnode等で作ったページにログインできるような技が知りたいな
先の技と似た方法でASP.Net Coreでクッキーだけ発行してnodeでも同じクッキーを使うのもいいけど、データベースを使い回す方法も見てみたい
だけどデータベースを見たところ、パスワードハッシュらしきものはすぐ見つかるもののソルト等がどこにあるのかよくわかんない
もしかしてハッシュに見える一部分がソルトなのか？パスワードハッシュらしきものは、どうやって生成されてる値なんだろう・・・・

**デフォルトの名無しさん** · 2020/10/19(月) 13:27:10.55

OIDC

**デフォルトの名無しさん** · 2020/11/02(月) 05:11:15.47

Blazor WebAssembly in .NET 5 is two to three times faster
for most scenarios. For more information,
see ASP.NET Blog: ASP.NET Core updates in .NET 5 Release Candidate 1.

.NET 5でかなり速くなるんだな
楽しみ

**デフォルトの名無しさん** · 2020/11/02(月) 12:21:12.29

Blazorで作ったうちのサイトに、大量のユーザ登録をする奴が出てきた
掲示板みたいなものがあるので、宣伝の書き込みに使いでも使うんだろうか？よくわからないけど不気味で仕方がない
大量登録を防いだり、ユーザーの行動をスコア化したりBANしたり、何かBlazorでできる手軽な対策ってない？

**デフォルトの名無しさん** · 2020/11/02(月) 13:05:27.82

>>657
しっかりやるならSMS認証だろうけど手軽ではないね。
手軽なのはメールアドレスとIPアドレスベース

登録時のメールアドレス認証はやってる？

同じIPから一定日数は登録できないようにすれば、
固定回線からの登録はある程度防げると思う
ISP次第で固定でもIP変更できちゃうけど
ただの宣伝目的ならそういうめんどうな
手順必要なところは避けてほか行くんじゃないか

**デフォルトの名無しさん** · 2020/11/02(月) 17:11:37.77

Azure AD使ったら多要素認証も気軽に実装できるよ

**デフォルトの名無しさん** · 2020/11/02(月) 22:47:48.58

>>659
そうなのか
全部クラウドでやるのは高すぎて避けたい。
認証だけAzure AD使うのってありなのかな

**デフォルトの名無しさん** · 2020/11/03(火) 02:39:12.95

>>660
もちろんありだよ

**デフォルトの名無しさん** · 2020/11/03(火) 19:52:22.74

>>657
迷惑行為なら通報したら？

**デフォルトの名無しさん** · 2020/11/04(水) 23:24:27.00

Blazorに限る話ではないかも知れないけど…

ServerにWeatherForecastController作って、
ClientからアクセスするときはGetFromJsonAsync<WeatherForecast>(“WeatherForecast”)とControllerの名前を「文字列」で引数に入れる。

これがせっかくここまでC#の型を使えてるのになんか無駄だなあと。
Shareにあるクラスは参照できてるのに、
なんでServerへのアクセスは文字列なのか。

ここタイプミスしたらオジャンじゃん。

外部のAPIならわかるけど、同じソリューション内のプロジェクトなんだから
WeatherForecastContoroller.GetAll WeatherForecast() でええやんと思ってしまう。

gRPCとか使ったらSOAPチックなことできるの？

**デフォルトの名無しさん** · 2020/11/05(木) 00:12:14.94

>>663
ハードコード避けたいときはnameofとかtypeof使うといいとかsampleかいてあったような。

//return CreatedAtAction("GetTodoItem", new { id = todoItem.Id }, todoItem);
return CreatedAtAction(nameof(GetTodoItem), new { id = todoItem.Id }, todoItem);

https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&;tabs=visual-studio
Web APIのTutorialのコード。

References the GetTodoItem action to create the Location header's URI.
The C# nameof keyword is used to avoid hard-coding the action name in the CreatedAtAction call.

**デフォルトの名無しさん** · 2020/11/05(木) 00:15:02.65

>>663
上みたいな感じで
Controllerの名前もなんらかのmethodでstringとして取得できるんじゃないかな

**デフォルトの名無しさん** · 2020/11/05(木) 00:17:59.90

てかWebAPIならAttribute Routingの方がよくね？

**デフォルトの名無しさん** · 2020/11/05(木) 08:21:04.21

>>664
nameofありだね
スペルミス減りそう

>>666
Attribute Routing調べたけど
API側でルーティングを文字列で指定してる。
文字列をやめたいんだけど…
メソッド名があるんだからメソッド名をそのまま使いたい。

そもそもREST APIの原則に囚われすぎな気がする。
毎回あんなURIを考えるのって大変じゃないか？

汎用性を考えるならわかるけど。

**デフォルトの名無しさん** · 2020/11/05(木) 08:27:25.47

>>663
それコントローラー名じゃなくてUriでしょ

DefaultRoute使えばuriとコントローラー名は一致するからそれでいいけど
プロジェクトの都合で
URIとコントローラー名異なるようにすることはあるでしょ。

**デフォルトの名無しさん** · 2020/11/05(木) 08:33:38.65

>>666
言ってることが分かったかも
API側で
[Route(“GetHogeData”)]
public Hoge GetHogeData(){}
にするってことかいな？

**デフォルトの名無しさん** · 2020/11/05(木) 08:34:41.52

すまんリロードせずに書き込んでしまった
そゆことね

**デフォルトの名無しさん** · 2020/11/05(木) 08:41:56.35

よくおぼえてないまま書くけど
ルーティングの機能でコントローラー名とアクション名から
アドレス作れたはずだから
それを渡せばいいんじゃないの
それだとnameofも利用できると思うし
カスタムルーティングの場合でも問題なくいけると思う

**デフォルトの名無しさん** · 2020/11/05(木) 23:38:47.81

razorファイルに書いたC#がバリバリ動くのは感動すら覚えるが
最初に作られるサンプルサイトがショボショボすぎてこれは普及しないだろうなあ…とおもう。

入力もできるグリッド、DateTimePicker、TreeView、モーダル
こういうのをサンプルに組み込んでもらわないと
いちいちググるはめになる。

**デフォルトの名無しさん** · 2020/11/05(木) 23:44:26.66

>>672
いやいやテンプレートに機能満載されてるほうが困るわ

**デフォルトの名無しさん** · 2020/11/05(木) 23:49:29.95

そんな複雑なUI作られても使う側が困るしなぁ
シンプルイズベストですわ
MVCでいいじゃないの

**デフォルトの名無しさん** · 2020/11/05(木) 23:52:06.81

>>672
お前はサンプルとテンプレートを混同している

**デフォルトの名無しさん** · 2020/11/06(金) 00:03:35.28

いろんなGUIサンプルはGitHubに置いておいてくれればいいね
Wizardで生成されたら困る

**デフォルトの名無しさん** · 2020/11/06(金) 08:08:26.77

テンプレートでもサンプルでもどっちでも良くて、
MSがそういうものを用意しないと流行らないと言っている。
そんなことをこんなところで言っても仕方ないけどな。

**デフォルトの名無しさん** · 2020/11/06(金) 11:00:07.02

コピペしかできない人なんだろう

**デフォルトの名無しさん** · 2020/11/06(金) 11:04:30.20

WebFormsぽとぺたさんにも使ってもらうなら要るかもねえ

**デフォルトの名無しさん** · 2020/11/06(金) 11:06:53.95

>>677
ウィザードでサンプル出力しろという主張だったのに都合よく主張変えるなよ

**デフォルトの名無しさん** · 2020/11/06(金) 12:30:57.02

MSはWebFormsの代替としてBlazor使えって言ってる。
使いたいがこれではハードル高いだろ。
外部の会社が作ってるUIコンポーネント集入れないと使い物にならん。

仕組み上ポトペタは無理としても、それに代わる何かがないと、学習コストがかかって採用されないよという話。

ウィザードでゴリゴリの画面が作られのもまずいというのはわかるが、さすがにシンプルすぎやせんか。

**デフォルトの名無しさん** · 2020/11/06(金) 12:39:05.16

単に自分の能力が足りてないだけじゃないの

まー言うとするなら
WebFormsのように基本的なコントロールは入れてほしい
って感じ？

サンプル云々の話じゃないよね

たぶん

**デフォルトの名無しさん** · 2020/11/06(金) 12:42:45.58

WebFormsってそんなに便利だったっけ？
あっという間にMVCに置き換えられたからわからねえや

**デフォルトの名無しさん** · 2020/11/06(金) 13:08:43.58

MVCにすら移行出来なかった層の
最後の救済目的がBlazorだからだろう。

**デフォルトの名無しさん** · 2020/11/06(金) 13:11:07.93

>>681
リッチUIを最速で作りたいならWPF使えばいい
外から使い人にはWindows tabletとか持たせるだけ。
Bootstrapでだいぶ敷居さがったがCSSベースのデザインはめんどくさい

>>683
HTML, CSSをよく知らない人、デザイン苦手な人には便利だったんだと思う
ただ細かいデザイン制御ができない、吐き出すｈｔｍｌが汚いから
ASP.NET MVCにとってかわられた

**デフォルトの名無しさん** · 2020/11/07(土) 22:13:36.96

Entity Framework使ってる人、Migration機能は使ってる？

Migration使うほうが複雑になる気がするんだけどどうだろう
Migrationのメリットが見えてこない

PostgreSQLのpgAdminとか
RDBの管理ツールで直接、スキーマの作成や変更をしてる。

**デフォルトの名無しさん** · 2020/11/07(土) 23:04:04.86

Ruby on Rails では、SQLite, PostgreSQL, MySQL の3大DB を、1つのファイルで定義できる(抽象化)。
Migration 用のファイルも、自動的に作られる

Roll Back もできる

Scaffold という魔法の呪文で、CRUD アプリが自動的にできる

**デフォルトの名無しさん** · 2020/11/07(土) 23:14:14.61

>>687
ルビーはどうでもいい

**デフォルトの名無しさん** · 2020/11/07(土) 23:33:27.49

>>686
アプリでSqliteなどのローカルDBでは凄く有効だが、サーバー弄れる場合は手動でいいと思うわ

**デフォルトの名無しさん** · 2020/11/08(日) 05:36:39.88

>>687
rollbackもできるというけどそれがMigrationの主要機能だし
rollbackできなかったら意味ないでしょ
Entity FrameworkのMigrationにもrollbackある。もちろんScaffoldもある

Rubyのコマンド見てみたがEFのMigrationと似てる気がした。
ORMが履歴を持つことでrollbackできるようになる半面、長ったらしいコードが
生成されその記述を理解しないといけなくなる。

DB側のカラムに制約とかデータ型とか細かく設定するべきだが
ORM使わずにpgAdmin, SQL Workbenchでやるほうが速いしわかりやすい。
さらにORM経由は操作できる範囲が限定される。
SQL使ってできる操作＞ORM使ってできる操作。

**デフォルトの名無しさん** · 2020/11/08(日) 05:42:09.04

>>687
RubyおじはASP.NET Coreは使えてるのか？
ASP.NET Core使えるなら低速なRails, Rubyなんて使わなくていいだろ

>>689
Sqlite以外ではMigration使ってないのか
本当にMigrationは誰得の機能かわからないわ

**デフォルトの名無しさん** · 2020/11/08(日) 09:47:27.03

それ言うならそもそもEntity Frameworkの存在意義自体がない気もするけど

**デフォルトの名無しさん** · 2020/11/08(日) 10:00:24.59

あー、SQL自動生成だけでも意義はあるか

まぁ、単に開発中のコードとデータベース同期を楽にする機能でしかないから
使いたければ使えばいいし
データベース熟知してて自分でDBスキーマ決めたいのならそうすればいいだけの話

**デフォルトの名無しさん** · 2020/11/08(日) 11:17:03.03

いちいち手作業でDBにつないで順番を間違えないように慎重にSQL実行して…
後で困らないようにどんなSQLを実行したかリリース履歴台帳に記入して…
手作業だからテストという概念もなくて…
これちょっとアナログすぎだしめんどくさいし間違えやすいんじゃねえか？って疑問を持つところがスタート地点
疑問すら持てないなら開発者として必要なセンスが欠けてる
紙とハンコのほうが性に合うオールドタイプならそのまま手作業を続けてどうぞ
ここは未開の原始時代

実行するSQLはファイルにしよう
SQLファイルのアップロードと実行はshellで自動化しよう
shellをソースコードと同じ所でバージョン管理したら便利だな
shellがバグってたらやばいから本番レプリケーションで事前にテストしよう
同じshellを間違えて実行したらやばいから実行履歴もテーブルで管理して多重実行を避けよう
これ全部1つのコマンドでできるように整備しよう
このように不便さを自動化で解消できたならすこしマシになった段階
産業革命の始まり
便利だけど色々と拙くまだまだコスパが悪い

shellは便利だけどオレオレ感が強くて属人生が高く保守しにくいな
なにか開発者間で共通認識となるフレームワークがあれば便利だろうな
MigrationをC#で書きたい場合もあるよな
そもそもshellの実行すらめんどくさいんじゃないか
などなど細かい不満点を解消していって出来上がったのがMigration系フレームワーク
ここがひとまずのゴール
より洗練されてエコな現代テクノロジの集大成

**デフォルトの名無しさん** · 2020/11/08(日) 11:27:42.43

ORM全般に言えることだけど、複雑になってくると使い物にならなくなる。
sansanもEFをDapperに置き換えたって発表してた。

正規化するのが正解じゃない時もあるし、サロゲートキーで対応

**デフォルトの名無しさん** · 2020/11/08(日) 11:32:46.67

途中で書き込んでしまった。
サロゲートキーだけではうまくいかない場合もある。

**デフォルトの名無しさん** · 2020/11/08(日) 11:52:36.61

>>695
CQRSのCではEFのほうが遥かに洗練されてる
Qでは高速で複雑なSQLを書きたくなる場合が増えてくるのでDapperが有利になる

多くの開発者が複雑化したQのせいでEFは使えないと思い込んでいるがEFはDapperと共存可能だ

更にいうと昔と違ってEFは随分と速くなった
ネイティブSQLもサポートしている
Dapperに頼らなくてもQを上手く実装することができるようなってる

**デフォルトの名無しさん** · 2020/11/08(日) 12:10:46.89

>>693
凄くどうでもいい事で申し訳ないがIDがSQL

**デフォルトの名無しさん** · 2020/11/08(日) 12:11:09.24

>>697
もう全然Blazor関係ない話で恐縮だけど…

大抵のDBって命名規約がスネークケースだよね。
しかも大文字か小文字のどっちか。

一度モデルファーストで作ったテーブルはキャメルケースで作られるから、生のSQL発行しようとしたらカラムIDを全部ダブルクォーテーションで括る必要があって苦労した苦い思い出がある。
LINQと生SQLどっちも使うとなるとこの問題に引っかかる。

自分のEFの知識が数年まえで止まってるのでいまはいい仕組みがあるのかな。

Dapperはパラメータで勝手にマッピングしてくれるから助かる。

**デフォルトの名無しさん** · 2020/11/08(日) 12:42:48.71

>>699
postgresqlは特殊な仕様だからハマりやすいね
なのでNpgsqlのEFにはUseSnakeCaseNamingConventionというオプションがある
他のDBは特にハマった記憶がない

**デフォルトの名無しさん** · 2020/11/08(日) 12:54:19.78

>>692-693
逆だよ。CRUDにEF使うのは便利だから意味がある。
C#のコードが短くなるし直感的にかける

だがスキーマの作成、変更でEF使うとC#のコードが長くなってしまう。
SQL側でダイレクトに変更すればすむものを履歴を持たせて
C#側から操作するから手順が増える。

スキーマが自動生成のものでいいってのはDB知らない奴だな
てきとうにつくるとパフォーマンス劣化する

**デフォルトの名無しさん** · 2020/11/08(日) 12:57:37.72

めんどくさいことになりそうな時は、RubyやRailsを勧めよう！

**デフォルトの名無しさん** · 2020/11/08(日) 13:03:31.26

>>694
原始時代って履歴台帳なんて古臭い言葉つかってるおまえだろう

スキーマ変更したら直後にテストしてるに決まってる
あと間違いやすいのは複雑な手順をとるMigrationのほうだ

**デフォルトの名無しさん** · 2020/11/08(日) 13:08:46.91

>>701
最近のEFは良くなってる
ほぼ想像どおりのスキーマを出力してくれる
とはいえ完璧とも言えない

完璧を求めるならMigrationを生SQLで手書きすることもできる
SQLを手書きしたいという要求のためにMigrationの全機能を手放すのは惜しい

**デフォルトの名無しさん** · 2020/11/08(日) 13:11:07.00

>>695
パフォーマンスの面でDapperは昔は意味あったとおもうけど
いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。

EFで満足できない箇所だけピンポイントでダイレクトにSQL使うか、
ストアドプロシージャを使えばいいと思うわ

>>697
たしかにEF Core速くなってるね
あとストレージがSSDになったのも超大きい

**デフォルトの名無しさん** · 2020/11/08(日) 13:15:04.98

>>703
いやいやスキーマを変更したあとにテストじゃ遅いだろ
Migrationをしてからテストするんじゃない
テスト済のMigrationを適用するんだ

ちなみにMigrationはアプリケーションをデプロイするだけなので手順ミスは最小化される
手作業でSQLを実行するとSQL数に比例してミスが増える

**デフォルトの名無しさん** · 2020/11/08(日) 13:17:19.61

>>704
ORM、DBのベンチマークたまに見てるし速くなってるのは知ってるよ。

ただstringとかの最適なデータサイズは開発者じゃないとわからないから
最適なスキーマ作ろうと思うとやっぱりSQLでスキーマ作成、変更したほうが
いいってのは今後も変わらないと思う

**デフォルトの名無しさん** · 2020/11/08(日) 13:25:09.54

>>706
根本的に会話になってない
俺の言ってるスキーマ変更するってのは決定事項なんだよ
既に正常に動くプログラムがあってそれをスキーマ変更するんだから
スキーマ変更した後にテストしないと意味ない。

Migrationでrollbackすることもない
動くようになるまで必要ならばC#側を変更するからだ。
なんかうまく動かないからスキーマ変更やめましょうということにはならない。

**デフォルトの名無しさん** · 2020/11/08(日) 13:33:40.14

>>707
EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ

より詳細な調整をしたい場合はMigrationを手書きしてMigrationBuilderに生えてるDDLラッパーを呼び出せば良い
DDLラッパーはCreateTableメソッド、DropTableメソッドなど.NETのメソッドではあるがDLLを書くのと非常に近い感覚で使うことができる
これはラッパーなので複数ベンダに対応することができる
代わりに最大公約数的な機能に制限されるが十分な機能揃っている

完全にMigrationをコントロールしたい場合には生のSQLを書いてもいい
EFはもちろん生のSQLもサポートしている
原始時代や産業革命時代に行っていたような作業はすべてEFでできる
ただし生のSQLを使うとベンダ依存が発生するのでそこはトレードオフだ

更に加えてMigrationとして.NETのカスタムコードを実行することが可能だ
例えば今まで保護されていなかった個人情報をC#で暗号化して保存し直すといったことも可能だ
手作業でSQLを実行する

**デフォルトの名無しさん** · 2020/11/08(日) 13:34:04.97

手作業でSQLを実行するだけではこのような複雑なMigrationには対応できない

**デフォルトの名無しさん** · 2020/11/08(日) 13:38:33.92

>>708
決定事項だろうがなんだろうがテストは必要だ

これからDBに対して行う変更を事前にテストする
テスト済の変更を確実にミスなく適用する

これを実行するための最もスマートな方法がMigrationだ
先程も書いたがこれをオレオレshellで代用することはできる
しかしそれは洗練された手法ではない
産業革命時代のやり方でしかない

もちろん適用したあとに最終チェックとしてテストを行うことはこちらとしても全く否定していない

**デフォルトの名無しさん** · 2020/11/08(日) 13:39:48.71

>>700
そんなのあるのか。EFにもどろうかなあ。
あとはバルクインサートやバルクアップデートができたら完璧。

**デフォルトの名無しさん** · 2020/11/08(日) 13:47:17.26

なおMigrationとその後のテストのどちらかが失敗した場合は
途中まで適用したMigrationをロールバックしなければならない
ロールバックはEFの機能で行うかDBバックアップをリストアするかどちらかだが
EFの機能で実施したほうが圧倒的に速い
リストアは最後の手段と考えよう

バグを放置してアプリケーションコードを修整するなどもってのほかである
これはサービスの停止時間を悪戯に伸ばすだけで損失を増やすばかりでなんの利益も産まない

バグがあったらロールバックを行い
Migrationとアプリケーション双方を見直し修整しテストする
テストした後にまたMigrationを適用する
これが現代人の働き方だ

**デフォルトの名無しさん** · 2020/11/08(日) 14:14:26.86

そういやMigrationって、データベースのデータの移行とかはできるもんなの？
できるのなら素人保守のSQLServerからPostgreSQLのマネージドデータベースに変えたいんだけど・・・・

**デフォルトの名無しさん** · 2020/11/08(日) 15:17:40.45

>>714
自分でコードを書けば柔軟できると思うけど
あるクラスのあるプロパティを別のクラスに移したいみたいなのは
自動生成では無理だと思う。

個人的にはmigrationは本番環境で使うものじゃなくて
開発中のコードとそれテストするときのデータベースの同期を楽にするもの程度で認識してる

**デフォルトの名無しさん** · 2020/11/08(日) 15:20:50.04

>>714
Entity FrameworkのMigrationはそういう機能はないよ
スキーマ変更の履歴を保持してロールバックとかができるだけ
俺はロールバックしたことないからめんどくさくなってMigration使ってない

Managedの維持費のがSQL Serverのオンプレミス維持費より高いんでは？
SQL Serverなんてバックアップ、リカバリできれば運用かんたんでしょう
DBの種類変更したらデータ型互換性なくなるから慎重にテストしないといけない。
よほど問題ない限り安定稼働してるDBはいじらんほうがいいとおもうよ

**デフォルトの名無しさん** · 2020/11/09(月) 15:36:48.48

https://www.youtube.com/watch?v=VPB_J6Egi28

**デフォルトの名無しさん** · 2020/11/09(月) 22:46:28.72

朝は動いていたStateHasChangedメソッドが、
昼になったら動かなくなった。
こんなセリフは一生使わないと思っていたが使わしてもらう。
何もしてないのに壊れた。

**デフォルトの名無しさん** · 2020/11/09(月) 23:19:22.08

何もしてないなら壊れたことも観測できないはず
何かをしたのは明白だ

**デフォルトの名無しさん** · 2020/11/10(火) 02:27:35.40

ウソをつくのはやめろ
お前は息をした

**デフォルトの名無しさん** · 2020/11/10(火) 13:07:54.58

長時間動かしてたんだったら、ゴミだと間違われてGCに回収されちゃったんじゃないの？

**デフォルトの名無しさん** · 2020/11/10(火) 18:27:27.96

>>718
昼休みだろ
もしくはハードウェア、ネットワーク障害

**デフォルトの名無しさん** · 2020/11/10(火) 20:49:01.81

Nuget使って気付いたけど.NET 5.0来てるな

RCなの知らずにNugetでUpdateしてしまった

**718** · 2020/11/10(火) 21:35:46.33

処理済み件数/全件数のパーセンテージ出してたんだけど
数値の型変えたり、全件数のカウントを変数に入れたりしたら出るようになったわ。
なんだったろうなあ…
なんらかの呼吸が悪さしたんだろうな…

**デフォルトの名無しさん** · 2020/11/10(火) 21:42:11.59

リリースノート見ると.NET 5.0 RC2けっこう前にでてたようだ
EFとかはNugetのPackageで5.0対応のがでてそれで気付いた。
バグ人柱になりたくないのでもう少し.NET Core3.1でいくわ

.NET Coreという名前ももうおしまいみたいだし

**デフォルトの名無しさん** · 2020/11/11(水) 05:33:40.57

New Git experience in Visual Studio 2019
https://www.youtube.com/watch?v=UHrAg3iKoe0

**デフォルトの名無しさん** · 2020/11/11(水) 07:22:02.02

デバッグに至るまでになかなか時間がかかるんだが、皆さんPCのスペックどれくらい積んでますか
会社のパソコンSSDは積んでるけど、メモリが8GBしかない。

**デフォルトの名無しさん** · 2020/11/11(水) 07:47:11.57

>>727
8GBあれば仮想化以外は余裕でしょ
遅いならCPUがへぼすぎるんじゃないかな？
CPU型番とPassmarkスコアは？
Dockerとかの仮想化つかってる？
仮想化つかうと滅茶苦茶おもいのは仕方ない

あとVisual Studioの中のSQL Server Object Explorer
あれは重すぎるな
DB専用の管理ツール使うほうが快適

**デフォルトの名無しさん** · 2020/11/11(水) 12:45:25.01

新規開発をするに当たってフロントの言語選定に悩む
Blazorを選択したいところなんだけどSilverLightのハシゴ外をされた件が怖すぎて

**デフォルトの名無しさん** · 2020/11/11(水) 12:47:54.87

クライアント版で開発すればサーバー側の実装まで一緒に死ぬことはないと思われるんだけど…
ReactじゃなくてBlazorを選ぶのか？と言われると揺らぐ

**デフォルトの名無しさん** · 2020/11/11(水) 13:30:01.83

>>729
あれはブラウザー内にデスクトップアプリ
動かすようなレベルのもんだから
何もってきても無理じゃね？

**デフォルトの名無しさん** · 2020/11/11(水) 13:45:18.87

フロントは使い捨て

**デフォルトの名無しさん** · 2020/11/11(水) 14:55:53.43

>>729
Silverlightと違ってWasmはstandardだから無くならない。

BlazorはMSだから長期サポートされる。
Reactとかは人気落ちたらセキュリティパッチすらでるか怪しい
サポート期間の長さでMSより安心できるベンダーはない

Blazor WebAssemblyならば、
server-sideをASP.NET MVC + Web APIsで作るわけで
これ以上、安心できるserver-sideはないだろう。
速度も速いし長期サポートあるしC#使えるし。
もしBlazor廃れたらWeb UI frameworkだけ入れ替えればいい

**デフォルトの名無しさん** · 2020/11/11(水) 16:54:13.95

速度が速いとウソをつく
↓
激遅の現状を突っ込まれる
↓
速度など問題じゃないと強がる

**デフォルトの名無しさん** · 2020/11/11(水) 16:56:17.09

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

**デフォルトの名無しさん** · 2020/11/11(水) 17:34:11.90

ドキュメントを読んでいて、コンポーネント間コミュニケーションのパラメーターやカスケードパラメーターが出てきたんだけどさ
便利そうだけど、これって使ったらコンポーネント同士が強固に依存しちゃうんじゃないの？
ファイルの編集・差し替えを繰り返すうちにスパゲティー化してきたり、いつか破綻しちゃわないか気になるな
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/components/?view=aspnetcore-5.0#component-parameters
https://docs.microsoft.com/ja-jp/aspnet/core/blazor/components/cascading-values-and-parameters?view=aspnetcore-5.0

**デフォルトの名無しさん** · 2020/11/11(水) 18:34:49.69

>>733
MSのLTSはあまり期待してないなぁ
ソース管理についてもTFSがフェードアウトしてる感あるよね？
かと言って、Githubにデータ移行はできないし
MSはこういう所が横暴でロックインし難い

**デフォルトの名無しさん** · 2020/11/11(水) 18:50:22.79

>>736
上位コンポーネントからパラメータで渡す分には問題ないと思う
通常のプログラミングでいうと関数的な使い方

カスケードプロパティは危険な臭いがプンプンする
これはグローバル変数のようなもの
俺はカスケードプロパティは全く使う気がしない

パラメータで渡さない場合は状態を管理するクラスを1個作ってInjectするといい
コンポーネントからはこのクラス経由でしか状態にアクセスしない
これはインメモリリポジトリのようなもの

**デフォルトの名無しさん** · 2020/11/11(水) 19:05:28.34

>>734-735
backendのベンチマークだ
JavaやC#が動的言語より速いのは常識
知らないやつは初心者

>>735
また計測不能ばかりのクソサイト張る無能
楽天も計測不能

**デフォルトの名無しさん** · 2020/11/11(水) 19:07:30.66

>>737
LTSは同類のほかのソフト出さないって意味じゃないだろ
セキュリティパッチ出てるならサポートしてるってこと
Googleとか他社はそれすらできてない

**デフォルトの名無しさん** · 2020/11/11(水) 19:23:06.81

遅さに関してはＭＳの責任者が１０倍遅いと言ってるし、
実際使うとともっさりしてんだよな。
サーバサイドのよりましだけど。

**デフォルトの名無しさん** · 2020/11/11(水) 19:32:33.32

>>741
10倍遅いというその発言も捏造
JS interopは.NET 5でかなり高速化したと発表されてる

wasmはよほどしょぼいハードの人以外は問題ないスピードになってる

**デフォルトの名無しさん** · 2020/11/11(水) 19:46:14.98

でも実際使うとともっさりしてんだよ。
JS interopの影響なのだろうけど、
処理概要を聞いたら感覚的に卒倒しとうなアーキテクチャだ。

サーバサイドのよりましだけど。

**デフォルトの名無しさん** · 2020/11/11(水) 20:34:50.42

むやみにevent呼ばなければ遅くならない
高速化のtipsも書かれてる
Blazor Serverの名前も出てこないようだしまともに
ドキュメント読んでるとは思えない

**デフォルトの名無しさん** · 2020/11/11(水) 20:39:05.32

>>734 の予言、当たってしまうｗｗｗｗ
速度が速いとウソをつく ( >>733 )
↓
激遅の現状を突っ込まれる ( >>735,741,743 )
↓
速度など問題じゃないと強がる ( >>742 )

**デフォルトの名無しさん** · 2020/11/11(水) 20:45:42.57

激遅の現状を捏造する

の間違いだな
実際速くなってるよ.NET5

**デフォルトの名無しさん** · 2020/11/11(水) 20:48:31.47

>>745
おまえアーキテクチャ全然理解してないのがバレバレ
backendとfrontendの違いも
WasmとBlazor serverの違いもわかってない

おまえはjQueryおじかweb app作れない奴だろうな

**デフォルトの名無しさん** · 2020/11/11(水) 20:51:59.41

Blazorはもともと高性能を目指したものではないからなーー。

https://ichi.pro/blazor-de-no-shumatsu-burauza-de-c-o-jikkosuru-118284362990616

開発者自身も了解している事じゃないの？
開発スタートの経緯を聞いてもそう思う。
偶然の産物なんだよ。このプロダクトは。

**デフォルトの名無しさん** · 2020/11/11(水) 21:27:58.47

>>740
あーそか
LTSは別の話だったね

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

EdgeだけでもC#がnativeで動くようにしちゃえばいいのにな
MSがブラウザの独自エンジン開発放棄したのは失敗だった

まさかのIE12でもいいよ
C# native実行できちゃうやつな

**デフォルトの名無しさん** · 2020/11/11(水) 22:59:52.25

メジャーフレームワークの事前ダウンロードオプションはそのうちサポートするんじゃないの
それか単にブラウザ拡張を作ればいい
事前キャッシュするだけだから簡単だろう