Microsoft ASP.NET Blazor #02

**デフォルトの名無しさん** · 2020/11/22(日) 05:30:30.13

ASP.NETのBlazorのスレッド part2です。

ASP.NET
https://dotnet.microsoft.com/apps/aspnet
ASP.NETは、クロスプラットフォーム対応、無料、オープンソースのフレームワーク
Free. Cross-platform. Open source.
A framework for building web apps and services with .NET and C#.

Introduction to ASP.NET Core Blazor
https://docs.microsoft.com/en-us/aspnet/core/blazor/?view=aspnetcore-5.0

【本命】Blazor スレ1【真打】
http://mevius.5ch.net/test/read.cgi/tech/1595255796/

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

>>250
全部dynamic型！みたいな言語だな。
こんなの自分一人でもだめだわ。破綻するわ。
これの利点ってなんなんだろ…

あとよくサーバーとフロントで型を共有できて嬉しいですよね♪みたいなこと書いてるブログもみるんだが
それができてない場合ってこうなる？
サーバー側:sexはなんか卑猥だからgenderにしたれ！
フロント側:sexに何も挿入されない…

**デフォルトの名無しさん** · 2020/12/23(水) 21:34:43.30

>>250
それはDictionaryに新しいkey/valueペアを追加してるのと同じだからね
そういうのでバグ出しちゃうのは基本的にテスト書かない人

チーム開発で動的言語使ってまともなプログラムを作るためには
静的言語の場合よりも高い技術スキルとコミュニケーション能力が求められる
なのでソフトウェアの規模というよりチームの規模が大きくなればなるほど不利

**デフォルトの名無しさん** · 2020/12/23(水) 21:52:55.12

無能爺が出しゃ張らないだけで、雑談スレでもここまで建設的なスレになるんだね

**デフォルトの名無しさん** · 2020/12/23(水) 21:53:23.50

>>253
サーバーとクライアントで違う言語を使ってても
swaggerとかでインターフェース定義してそれぞれコード生成すればいい
C#でも同じだと思うんだけど？

逆に同じ言語を使ってるからといってやり取りするデータを定義した
クラスライブラリを共有するのはアーキテクチャ的にはかなり微妙
特に外部に公開するようなサービスでは

**デフォルトの名無しさん** · 2020/12/23(水) 22:03:15.12

>>254
これだけのことにテスト書くの？テストまみれにならないか？
そもそもコンパイラがチェックしてくれるようなこおを自力でテスト書くとか苦行すぎるだろ…
それって高い技術力と言っていいのだろうか。
言語、フレームワークの選定を間違えているとおもう。

>>256
Blazorのプロジェクトつくるとそうなってるよね
あれは規模が小さいシステムなら許容されるんだろうか。

**デフォルトの名無しさん** · 2020/12/23(水) 22:27:01.33

>>256
連投すまん

そのswaggerはサーバー側の型に変更があったらクライアント側で気づくことができるんだろうか。
blazorのプロジェクトの構成ならコンパイラが教えてくれるよね。

外部に公開しないシステムで二回型定義するのは、ツールに頼ったとしてもめんどくさいとおもってしまうんですよ

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

>>258
swaggerの意味間違えてるよ。
それswaggerの役割じゃないから。

**デフォルトの名無しさん** · 2020/12/24(木) 00:38:15.61

Unityがなんで勝ったか、を考えれば答えは見えてるだろ

**デフォルトの名無しさん** · 2020/12/24(木) 00:59:13.90

>>257
>Blazorのプロジェクトつくるとそうなってるよね

なるほど、前提として想定してるアーキテクチャが全然違ったのね
>>256の話はBlazorのプロジェクトが別のバックエンドのAPIサーバーにアクセスする必要があるようなケースに
APIサーバーがで定義された型をクラスライブラリとしてBlazorのプロジェクトと共有するかどうかみたいな話ね

Blazorはモノリシックなアプリでいい場合は簡単に作れていいと思うよ
考え方的にはRailsとかと同じだけど裏のところが独自技術な分だけ優れてる
悪い点はロックインされるところ

**デフォルトの名無しさん** · 2020/12/24(木) 01:05:39.49

最近はミクロサービスもやっぱ駄目だったってんでモノリスに回帰してきてるらしいな

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

Docker は、1コンテナに、1アプリのマイクロサービス

今の基幹技術だろw
流行りまくっている

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

>>263
またにわかのフロントエンドのバカか
流行っているかではなく優れているかで選ばなくてはいけない
大規模やってる大手企業、上級エンジニアはDockerを嫌う

**デフォルトの名無しさん** · 2020/12/24(木) 08:34:44.70

>>261
すまん前提が書けてなかった。
うちは企業内アプリをメインに作ってて、他の外部apiには殆どアクセスしない。
バックもフロントも自チーム内で完結する。

横に座ってる奴がサーバー側の型を変更して急用ができて帰ったとする
フロントやってるやつがそのことに気づかずにリリースしてしまうなんてことが起こるようなら本末転倒だなと。

それで原因はテストコードが足りないとか、コミュニケーションが足りないとかいうのもおかしいよねと考えている。
Blazorのプロジェクト構成ならビルド時に気づくよね。

swaggerを使うことで、フロント側がすぐに型変更を検知できるような仕組みがあるんならいいんだけど、気づかないよね？困るよね？現にお困りではないでしょうか？
と聞きたかった。

**263** · 2020/12/24(木) 08:39:38.18

AWS の構成図を見てみろ。
ほとんど、マイクロサービスだろ

何十もの、Lambda, SQS(Queue), SNS(通知)をつなげてるの、ばっかりだろ

クラスメソッドの動画を見ろ

会社全体で、AWS の資格を800持っていて、
全12資格を持つ・ジェダイマスターが7人もいる！

**デフォルトの名無しさん** · 2020/12/24(木) 08:40:41.97

>>264
零細爺が見栄張って適当言っちゃあかんでしょ
社内でファイルサーバーでもたててSEごっこしてなさい

**デフォルトの名無しさん** · 2020/12/24(木) 08:53:01.08

>>266
そりゃアマゾンは大手のクラウド事業者だからあたりまえだろ
自社の提供するサービスをそのまま使ってるだけ
サービスの広告にもなる

一般法人がそれを採用することが合理的かは別の話だ。
デメリットを理解せず、流行ってるからいいという
アホな価値観だからそういう思考になる

**デフォルトの名無しさん** · 2020/12/24(木) 08:58:23.93

こいつはホンマにいつも5chやっとるな

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

>>266
おまえいつもKENTAの話ばっかりしてるやつだろｗ
クラスメソッドｗ
俺は初心者向けスクールなんていかない。

会社全体の資格者数なんて何の意味もないし
ベンダー資格なんてすぐに取れるんだよｗ
スクールだから宣伝のために講師に取らせてることも理解できないって
頭悪すぎだぞ
スクールの講師に優秀なエンジニアいないぞ
簡単にとれる資格でだまされてるやつｗ
KENTAとかスクールとか情弱ビジネスに釣られすぎ

**263** · 2020/12/24(木) 09:33:54.56

クラスメソッドは、AWS パートナー・オブ・ザ・イヤーとか取ってる、最上位の会社

米国年収で、
Ruby on Rails 1,300万円
Node.js 900万

VMware 1,400万
AWS Solution Architect 1,500万

もう、AWS資格が、Railsを超えてる！

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

ついでに聞いとこ。
クラスメソッドくんは普段なんのフレームワークで開発してるんだい？

**デフォルトの名無しさん** · 2020/12/24(木) 10:54:27.41

>>266
その構成が複雑化しすぎて多くの場合でデメリットがメリットを上回ってしまう
よっぽど巨大で複雑なシステムでもない限りモノリスのほうがシンプルでイイネ
っていうふうにトレンドが移り変わろうとしてるところ

**デフォルトの名無しさん** · 2020/12/24(木) 11:28:27.57

KENTAはコテ付けるべきでは？

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

>>273
これほんとにそうだと思う。

こういうのが必要なのって相当巨大なシステムだけなんじゃないのか
トレンドだからとDockerだか、Kubernetesだかに手を出して
気づかず消耗してるんじゃないだろうか。

クリーンアーキテクチャについてもそうおもうし、
なんならrest apiもそうなんじゃないだろうかと疑っている。
rpcでよかったのにrestにしちゃったケースもあると思うんだよなあ

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

>>265
サーバー側の型が
クライアント側に漏れでた時点で
設計がおかしい。

もしかして、
クラサバみたいな設計ですか？

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

>>276
漏れ出るって…？
ASP.NET MVCは定義したモデルをビューで参照できるよね？
これは漏れ出てる…？

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

>>275
Dockerは別にいいと思う
あれはどんな依存関係でも簡単にパッケージできるのと環境を汚さないで済むという強力なメリットがある
K8Sまで行くとやりすぎで本当にK8Sが必要なのか慎重に考えないといけない

クリーンアーキテクチャは悪くない
モノリスに回帰してきているとは言ってもコードを汚く書いていいわけじゃない
あくまでも悪いのはミクロサービスであってアプリケーション内部をクリーンアーキテクチャで綺麗に構造化するのは依然として良いことだ

RPCはそのとおり
APIだけじゃぜんぜん駄目だったのでgRPCなどが普及し始めた
DDDの文脈で綺麗にシステムを作ろうとするとAPIよりRPCが肝要となる

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

>>277
サービスレベルで設計してないって事ね。

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

単純なマスタメンテみたいなアプリでもなけりゃサーバーとクライアントで扱うモデルって一致しなくない？
セキュリティとかプライバシーに関わるようなデータでも平気でネットワークに流しちゃう感じ？

**デフォルトの名無しさん** · 2020/12/24(木) 14:00:28.72

ドットネッターはコンテナに拒否反応示す人が多いよね
.NET Coreでせっかくモダンなスタイルのデプロイが可能になったと思ったら、
井の中の蛙なユーザーに迎合してIIS統合とかFDD強化とか変なことに力入れてどんどん退行してるし

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

Windowsコンテナが実用レベルになったら起こしてくれ

**デフォルトの名無しさん** · 2020/12/24(木) 17:59:56.32

>>279
そこまでやる必要がないレベルといえばそう。
世にあるMVC系のWebフレームワークはなんか漏れ出してるということなんだろうか

>>280
逆に単純なマスタは一致するんじゃないの
そりゃおっしゃるようなシーンでは一致しないだろうけど
どっちが多いかにもよるんだろうか。

サーバーと型が共有できるって利点だと思っていたけど
結構反対意見も多いな。
少なくともBlazorの雛形はそうなっているけど、これは小規模だから成り立っている？
もっといろんな意見を聞きたい。

**デフォルトの名無しさん** · 2020/12/24(木) 18:17:21.72

>>283
反対意見じゃなくてAPIの設計がちがう。

swaggerでopenAPIとして公開するレベルなら、
クライアントの種別、言語は問わない。

**デフォルトの名無しさん** · 2020/12/24(木) 18:32:45.65

>>265
それってコンパイルエラーになるような変更なら気がつくけど
それ以外の変更なら不具合が起こってても気が付かないてことでしょ？
結局テスト書いてないだけじゃない？

swaggerとかインターフェース定義ファイルからそれぞれのスタブを自動生成するようなやつは
定義が変わればそりゃ検知できるけど検知できて新しい定義に対応したところで
その変更によって不具合が起こってないことはテストしないとわからないよね

**デフォルトの名無しさん** · 2020/12/24(木) 18:36:25.33

>>280
モデルにも色々ある
ドメインモデルとかビューモデルは当然、共有しない

APIやRPCのI/Oモデルは共有する
Blazorはこれを追加作業なしで完全な形で型安全に共有できるから強い

**デフォルトの名無しさん** · 2020/12/24(木) 18:46:02.72

さらにF#の型プロバイダをBlazorで利用すると、バックエンドが.NETでない場合でも、型安全なI/Oモデルを手に入れることができる
インターフェース定義、コード生成要らないので、とても楽ちん

**デフォルトの名無しさん** · 2020/12/24(木) 18:53:41.80

>>284
いろんなデバイスやシステムからアクセスするapiに関してはおっしゃる通りだと思うよ。
でもそんなの限られるんじゃないの？いや俺がそういうの作った事ないからそう思い込んでるだけかもしれないけど。

そうじゃないものまでapi化するのは意味なくて、型は共有した方が嬉しいですよね♪ってことだと解釈してます。

>>285
swaggerはリリース前に自動で変更検知して止めてくれるってこと？
なら安心だな。
テストに関してはおっしゃる通り。

**デフォルトの名無しさん** · 2020/12/24(木) 19:15:50.43

>>283
型共有は工数削減効果が非常に高いので積極的に利用して良いよ

**デフォルトの名無しさん** · 2020/12/24(木) 19:26:12.20

swaggerがどうのこうの言ってる人はミスリードを狙ってそうな気配がする
swaggerはメソッドを定義することはできないからblazorの型共有とはそもそもまったくの別物だよ

**デフォルトの名無しさん** · 2020/12/24(木) 19:34:01.95

blazorの型共有は単にAPIのDTOを共有するといったつまらないユースケース留まらない(もちろんDTOとしても非常に便利ではあるが)

例えば単価、税率、個数から消費税込み価格を計算するメソッドがプレゼンテーション層とドメイン層の両方で必要になった場合
blazorならC#で1回だけメソッドを実装すればいい
バックエンドとフロントが異なる言語だと同じ処理を異なる言語で2回実装しなければならない
もちろん仕様変更が発生した場合には両方ともプログラムを修正、テストをしなければならない
テスト定義もバックエンドの言語とフロントエンドの言語で2回書かなければならない
片方の仕様変更を忘れてもテストが更新されなければアラートは鳴らないので
慎重に2つの言語を調べ尽くして実装漏れがないかどうか確認しなければならない

**デフォルトの名無しさん** · 2020/12/24(木) 20:36:59.38

画面の金額と実際の請求金額に差異が出たりしたら偉い人が顧客に土下座するレベルの重大事故だろ
さすがにそこはサーバーサイドに投げるわ
コード共有などという小手先レベルの共通化は少々バグっても笑って許される程度の機能のちょっとしたUX改善程度にとどめておくべきで、
重要なものはアーキテクチャ上差異が発生しないように作る

**デフォルトの名無しさん** · 2020/12/24(木) 20:48:02.28

>>292
この例はあくまで一例
実際のシステムでは金額計算以外にも同じような状況は沢山ある
それをいちいち全部バックエンドに問い合わせるのは実行効率も製造効率も悪い

**デフォルトの名無しさん** · 2020/12/24(木) 20:58:24.94

>>291
コピペ？

swaggerを使ってのopenAPIなら
まずはその設計思想を勉強されてみてはどうでしょうか？

googleのAPIとか参考になりますし、
無料で試せますよ。

**デフォルトの名無しさん** · 2020/12/24(木) 21:06:28.06

>>292
自分の設計だとバリデーション含めて
ロジックは全部（表示フォーマットも）サービス側ですね。
ローカルにあるロジックと応答速度で遜色ないですよ。

サービス側は全部単体テスト対象なんで
安心感もあります。

リリース後にバグ出すと、
なんで単体テストを通過したのか始末書もんです。

**デフォルトの名無しさん** · 2020/12/24(木) 21:23:01.51

>>295
思想としては正しいと思う
.NETな人って表面的なコードの共有は大好きなのにデプロイメントをDRYにするという意識が希薄な人が多くて、
ビジネスロジックのDLLをWebとバッチで安易に共通化したりしてデプロイをミスってトラブル起こすケースが多いんだよね

**デフォルトの名無しさん** · 2020/12/24(木) 21:32:29.46

View側に業務ロジック混ざると、
コードが読めなくなること多いですからね。
いろんな人が出入りするし。

フロントなんて持って数年、
システムの統廃合やリプレース時にも楽ですよ。

**デフォルトの名無しさん** · 2020/12/24(木) 21:48:16.63

Blazor Serverでファイルのアップロード処理をしたいのですが、
アップロード時に、ローカルにファイルが存在するかチェックするにはどうすればよいでしょうか？

**デフォルトの名無しさん** · 2020/12/24(木) 21:51:51.36

>>298
ローカル側の処理なんでJavaScript書かないと仕方ないんじゃないの

**デフォルトの名無しさん** · 2020/12/24(木) 21:59:31.17

>>299
ありがとうございます。
該当部分はJavaScirptで作ります。

**デフォルトの名無しさん** · 2020/12/24(木) 22:00:26.68

>>294
swaggerはblazorの型共有とは違うベクトルの話だよ
ここで話すべき内容ではない

**デフォルトの名無しさん** · 2020/12/24(木) 22:05:56.79

>>295
それはいままで簡単にフロントエンドとバックエンドでロジックを共有できなかったからそうするしかなかっただけ
型共有がなかったからコードを重複させるか些細なことでもバックエンドにリクエストを出すしかなかった
どちらもやりたいことにたいして実装と実行のオーバーヘッドが大きい
型共有が可能なblazorでは無駄なエンドポイント実装、APIコール実装を削減することにより生産性の向上が期待できる
また無駄なラウンドトリップを避けることによりより良いユーザー体験が期待できる

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

>>296
昨今ではデプロイメントは自動化されるので間違えることはない

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

>>297
Viewには業務ロジックは混ざらない
Viewからは業務ロジックを呼び出すだけ
今まではAPIを通じてリモート呼び出ししていたがblazorではその必要なく呼び出せる

**デフォルトの名無しさん** · 2020/12/24(木) 22:25:28.29

>>304 >>302
「Blazorでは」と書くと正しく伝わらない。
Blazor ServerとBlazor WebAssemblyで全然違う
紛らわしい名前つけたMSが悪いんだが。

**デフォルトの名無しさん** · 2020/12/24(木) 22:50:48.81

実際どちらのことを書いてるんだろう
Serverかな
しかしwasmとserverでほんと全然ものが違うよな。
共通点はフロントをc#でかけるってだけで。

MSの名前の付け方は本当に適当だと思う。

**デフォルトの名無しさん** · 2020/12/24(木) 22:59:35.56

同一言語で作ってる同一プロジェクト内で型を参照することを
”型共有”って言うのは相当違和感あるね

誰が使い始めたのかしらないけど

**デフォルトの名無しさん** · 2020/12/24(木) 23:11:34.69

では何と言うべきか？

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

Qiita や個人のブログを貼るのはアレなので
クラスメソッドの記事を…

https://dev.classmethod.jp/articles/typescript-front-server/

interfaceを共有することで型安全な開発ができます

これのことかな。

**デフォルトの名無しさん** · 2020/12/24(木) 23:50:47.46

Blazorはinterfaceの共有もできるがそれだけに限らない
interface、class、struct、、、何でも共有できる
それらを総称するとなんと言うか？それは型だ
だから型を共有していると言うより適切な表現はないのではないかな

**デフォルトの名無しさん** · 2020/12/25(金) 00:08:08.33

>>309
このケースはリポジトリとして定義した型をサーバーとクライアントで共有してるというのは違和感ないな
RESTのAPIで切り離されてるからかな
(APIが返す型情報を元にしてないから微妙なところがあるけど)

ASP.NET MVCで言えば同じビューモデルの定義を参照してるからって
ビューとコントローラーで”型共有”してるとは普通言わないよね？

**デフォルトの名無しさん** · 2020/12/25(金) 00:14:35.63

>>311
言い回しとして普及してるかどうかは知らんが型を共有してるのは正しい

**デフォルトの名無しさん** · 2020/12/25(金) 00:24:51.99

>>311
Blazor wasmのプロジェクト構成では
Shareプロジェクトにモデルを定義して
ClientプロジェクトのRazorページでShareプロジェクトを参照している
同じくServerプロジェクトのコントローラーでもShareプロジェクトを参照している
これはなんていうんだろう。

どちらにせよサーバーとクライアントで同じ型を使うという目的に対して手段が違うだけであって、別にまずくはないと思うんだけどどうだろう。

**デフォルトの名無しさん** · 2020/12/25(金) 08:42:56.78

サーバーとフロントで型を共有？できた方が大半はうれしい。
OpanAPIが必要なシステムではそこに固執しなくてもよいということで。

じゃあこの板でもたまにやたらと推してくる奴がいる言語、rubyやpythonって静的型付け言語じゃないよね。
てことは型の共有もくそもないと。

そういう言語で中規模以上のWebシステムを作ろうとするとやはり苦労する？
推してくるやつはその事実をわかっていない？
静的型付け言語しかしらない俺にとってはなんであんな推してくるのかとても気になる。

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

>>314
OpenAPIじゃメソッド(処理)を共有できないよ
フロントエンドとバックエンドで言語を揃えることにより今まで複数言語で書くかリモート実行するしかなかった問題が解決した
OpenAPIは複数言語で書く手間を軽減できるがリモート実行するしかないという問題には未だに無力

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

どんな言語であれフレームワークであれ
データ型は共有しないとクライアントが受け取ったデータを適切に処理できないでしょ

blazor は同じアセンブリを共有できる分開発は楽になるでしょ

クライアントに送るデータはクライアントに必要なデータしか普通は送らないし
サーバ側の型がクライアントに漏れるとか
入門書レベルの開発しかしたことないだろ

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

>>315
多種多様なシステムやデバイスが使うapiは仕方がないという認識

**デフォルトの名無しさん** · 2020/12/25(金) 10:04:08.77

>>317
その多種多様なデバイスの上で.NETが動くわけで

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

ぜんぶ設計者次第だという認識

**デフォルトの名無しさん** · 2020/12/25(金) 10:16:11.17

>>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する

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

>>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている

昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
プレゼンテーションレイヤから直接ドメインレイヤを参照できればそれが最もシンプルでよろしい

もしそれができない場合、プレゼンテーションレイヤにも税込み価格計算ロジックを実装するかリモート呼び出しのためのエンドポイントを実装し、APIクライアントも実装するという重い作業を強いられる

もちろん、税込み価格計算はただの一例であり、実際にはより多くのニーズがある
プレゼンテーションレイヤからドメインレイヤの型を参照できると低コストでより高度な画面を作成することができる

**デフォルトの名無しさん** · 2020/12/25(金) 10:22:24.07

>>320
それはどうかな？
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう

**デフォルトの名無しさん** · 2020/12/25(金) 10:27:26.49

そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない

**デフォルトの名無しさん** · 2020/12/25(金) 10:32:50.39

>>314
自分で勉強しろって
ここで言ってる”型共有”はRubyでもPythonでもできてる

>>315
“メソッドを共有”って何なの？
処理を共有するためのAPIなんだけど・・・
それにBlazorもリモート実行してるよ

**デフォルトの名無しさん** · 2020/12/25(金) 10:35:51.93

>>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない？
しんどくない？しんどくてもその分の見返りがRubyにはある？

いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。

**デフォルトの名無しさん** · 2020/12/25(金) 10:38:07.26

>>324
あれ、RubyやPythonも型があるのか
失礼しました。
もう自分で触ってみないとわからんな…

**デフォルトの名無しさん** · 2020/12/25(金) 10:38:47.43

>>321
そんなこといったら
クライアント側でのデータ検証なんて　何もできない

**デフォルトの名無しさん** · 2020/12/25(金) 11:01:46.48

静的型チェックを重視するならC#よりF#使えばいいのに

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

訳わかんない理論がまかり通るスレ

**デフォルトの名無しさん** · 2020/12/25(金) 11:37:26.72

>>324
リモート実行は外部処理系に処理を依頼しているだけなので共有ではない

ここでいうメソッドの共有とは異なる処理系が同じ実行コードをそれぞれの内部に持っているということ

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

>>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる

**デフォルトの名無しさん** · 2020/12/25(金) 11:49:27.10

>>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている

ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット

フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる

もちろんデータ検証以外の処理もおなじこと

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

>>331
そう。その何かしらのメリットを知りたいのだ…

>>245
>>250
はjavascriptの例だが、これがrubyでも起こるとすると
しょーもないCRUDの画面でもテスト書かないといけないのだろうか。

javascript勢がTypeScriptに流れてるってことは
それなりの規模のあぷりを動的型付け言語でやろうとするといくらテスト書いても辛いって事だと思うんだけど。

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

それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ

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

だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い

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

>>321
明日もお願いします。

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

Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし

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

>>333
動的言語はコード編集から動作確認、テスト実行開始までがとにかく早い
なのでゼロベースの新規プロジェクト、サービス公開までの時間を最優先する場合にはデメリットよりメリットが上回る

**デフォルトの名無しさん** · 2020/12/25(金) 13:33:23.39

>>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
ＪSやJavaのスレッドはある
Java Web Application Framework総合　ver2
http://mevius.5ch.net/test/read.cgi/tech/1374399677/

C#は乱立してないから素直にASP.NET使えばいい
5chみたいな狭い世界で比較検討せずに
素直に人気のあるやつをいくつか試して決めた方がいい。

**デフォルトの名無しさん** · 2020/12/25(金) 13:37:24.42

>>337
うざがられてあたりまえ
JSやってるやつらのほとんどがC#を使えない

C#使えるならバックエンドは迷わなくていいASP.NETでいい
迷うならフロントまわりの技術

**デフォルトの名無しさん** · 2020/12/25(金) 13:55:33.58

自演ぽいな

**デフォルトの名無しさん** · 2020/12/25(金) 14:03:41.81

そろそろ学習本が欲しいところ
アレ以外で

**デフォルトの名無しさん** · 2020/12/25(金) 14:22:22.25

>>330
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね

異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ

**デフォルトの名無しさん** · 2020/12/25(金) 14:24:09.99

>>343
ではなんと言ったらわかりやすい？

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

共通するコードをライブラリ化して共有でいいんじゃないの

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

バッと来て
グッと溜めて
ブワッ！

**デフォルトの名無しさん** · 2020/12/25(金) 18:29:51.37

>>345
長いので1単語にまとめて

**デフォルトの名無しさん** · 2020/12/25(金) 19:21:45.07

>>340
そうなんだろうか
実はC#erが食わず嫌いなだけで、実はあちらのほうがめちゃくちゃいいものなのかもしれないよ…？

**デフォルトの名無しさん** · 2020/12/25(金) 19:30:34.79

以前は asp.net は Windows Server でしか動かなかったからなぁ

今でこそようやく Linux でもまよもに動くようになって2年ぐらい？

twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな

まだまだこれからでしょ

**デフォルトの名無しさん** · 2020/12/25(金) 20:54:05.41

>>348
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ

JSのbackendのweb frameworkか？
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ

スクリプトは遅い。開発の生産性が低い
これは開発者の常識
高速なハードとソフトを合わせないとスケールするサイトにできない

**デフォルトの名無しさん** · 2020/12/25(金) 20:56:57.60

>>349
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い

**デフォルトの名無しさん** · 2020/12/25(金) 21:08:02.22

高速なコードで作りたかったらstaticに限る。
主要OSの主要な言語はstaticだ

Swift, Kotlin, Java

server-sideでKotlinもあり。

**デフォルトの名無しさん** · 2020/12/25(金) 23:41:23.33

サーバーとクライアントは同じ言語の方がいいんだろ？