[過去ﾛｸﾞ] Microsoft ASP.NET Blazor #02 (608ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
311(2): 2020/12/25(金)00:08 ID:vv0pxJyE(1/3) AAS
>>309
このケースはリポジトリとして定義した型をサーバーとクライアントで共有してるというのは違和感ないな
RESTのAPIで切り離されてるからかな
(APIが返す型情報を元にしてないから微妙なところがあるけど)
ASP.NET MVCで言えば同じビューモデルの定義を参照してるからって
ビューとコントローラーで”型共有”してるとは普通言わないよね？
312: 2020/12/25(金)00:14 ID:K5aqSQYy(1) AAS
>>311
言い回しとして普及してるかどうかは知らんが型を共有してるのは正しい
313: 2020/12/25(金)00:24 ID:Z26lwPgE(1/2) AAS
>>311
Blazor wasmのプロジェクト構成では
Shareプロジェクトにモデルを定義して
ClientプロジェクトのRazorページでShareプロジェクトを参照している
同じくServerプロジェクトのコントローラーでもShareプロジェクトを参照している
これはなんていうんだろう。
どちらにせよサーバーとクライアントで同じ型を使うという目的に対して手段が違うだけであって、別にまずくはないと思うんだけどどうだろう。
314(3): 2020/12/25(金)08:42 ID:uurLZNKt(1/8) AAS
サーバーとフロントで型を共有？できた方が大半はうれしい。
OpanAPIが必要なシステムではそこに固執しなくてもよいということで。
じゃあこの板でもたまにやたらと推してくる奴がいる言語、rubyやpythonって静的型付け言語じゃないよね。
てことは型の共有もくそもないと。
そういう言語で中規模以上のWebシステムを作ろうとするとやはり苦労する？
推してくるやつはその事実をわかっていない？
静的型付け言語しかしらない俺にとってはなんであんな推してくるのかとても気になる。
315(2): 2020/12/25(金)09:13 ID:JfQSa+1c(1/10) AAS
>>314
OpenAPIじゃメソッド(処理)を共有できないよ
フロントエンドとバックエンドで言語を揃えることにより今まで複数言語で書くかリモート実行するしかなかった問題が解決した
OpenAPIは複数言語で書く手間を軽減できるがリモート実行するしかないという問題には未だに無力
316(1): 2020/12/25(金)09:31 ID:UA1/tVeu(1/4) AAS
どんな言語であれフレームワークであれ
データ型は共有しないとクライアントが受け取ったデータを適切に処理できないでしょ
blazor は同じアセンブリを共有できる分開発は楽になるでしょ
クライアントに送るデータはクライアントに必要なデータしか普通は送らないし
サーバ側の型がクライアントに漏れるとか
入門書レベルの開発しかしたことないだろ
317(1): 2020/12/25(金)09:44 ID:uurLZNKt(2/8) AAS
>>315
多種多様なシステムやデバイスが使うapiは仕方がないという認識
318: 2020/12/25(金)10:04 ID:JfQSa+1c(2/10) AAS
>>317
その多種多様なデバイスの上で.NETが動くわけで
319: 2020/12/25(金)10:09 ID:8j4BK9K7(1/3) AAS
ぜんぶ設計者次第だという認識
320(1): 2020/12/25(金)10:16 ID:81Ut/TdK(1) AAS
>>314
WebなんてぶっちゃけDBと画面の間のマッピングを定義してるだけの話なので、
データモデルがRDBによって常に静的に型付けされているため動的型でも破綻しにくい
むしろ変にドメイン駆動とか意識高いのに毒されて画面から独立したモノリシックなビジネスロジック層みたいなのができちゃうと、動的型では確実に破綻する
321(2): 2020/12/25(金)10:17 ID:JfQSa+1c(3/10) AAS
>>316
サーバー側の型がなにを指しているのかによるな
データアクセスレイヤのクラスがプレゼンテーションに漏れるのはBADだと思う
しかしドメインレイヤのクラスをプレゼンテーションから参照するのは問題ないと考えている
昨日も例を出したけど
入力として単価、消費税率、個数があってリアルタイムに税込み価格を表示する画面があったとする
この税込み価格の計算は明らかにドメインロジックだ
省4
322(1): 2020/12/25(金)10:22 ID:JfQSa+1c(4/10) AAS
>>320
それはどうかな？
意識の高いプログラマの代表格であるマーチンファウラー先生はrubyを称賛していたね
ドメインを実装するのに必ずしも静的でなければならなということはなさそうだ
重要なのはテストを書くことなのだろう
323: 2020/12/25(金)10:27 ID:JfQSa+1c(5/10) AAS
そもそもWEBをひとくくりに画面とDBのマッピングであると決めつけるのもいかがなものか
チュートリアルみたいな簡単な仕事ならそれでもいいのかもしれないが
現実のビジネスは小さな事業でもそんなに簡単にはいかない
324(2): 2020/12/25(金)10:32 ID:vv0pxJyE(2/3) AAS
>>314
自分で勉強しろって
ここで言ってる”型共有”はRubyでもPythonでもできてる
>>315
“メソッドを共有”って何なの？
処理を共有するためのAPIなんだけど・・・
それにBlazorもリモート実行してるよ
325(1): 2020/12/25(金)10:35 ID:uurLZNKt(3/8) AAS
>>322
C#であればコンパイラが型チェックしてくれるようなことすらも
Rubyは自力でテストを書かなければならない？
しんどくない？しんどくてもその分の見返りがRubyにはある？
いや数画面のスキャフォールドで作られたようなCRUDシステムなら好きな方選んだらいいと思うんだけど
中規模以上になってくるとどうなのかなと思って。
326: 2020/12/25(金)10:38 ID:uurLZNKt(4/8) AAS
>>324
あれ、RubyやPythonも型があるのか
失礼しました。
もう自分で触ってみないとわからんな…
327(1): 2020/12/25(金)10:38 ID:UA1/tVeu(2/4) AAS
>>321
そんなこといったら
クライアント側でのデータ検証なんて 何もできない
328: 2020/12/25(金)11:01 ID:bbGDaeBs(1) AAS
静的型チェックを重視するならC#よりF#使えばいいのに
329: 2020/12/25(金)11:08 ID:8j4BK9K7(2/3) AAS
訳わかんない理論がまかり通るスレ
330(1): 2020/12/25(金)11:37 ID:JfQSa+1c(6/10) AAS
>>324
リモート実行は外部処理系に処理を依頼しているだけなので共有ではない
ここでいうメソッドの共有とは異なる処理系が同じ実行コードをそれぞれの内部に持っているということ
331(1): 2020/12/25(金)11:45 ID:JfQSa+1c(7/10) AAS
>>325
動的言語はしんどいよ
自分個人としては動的言語には懐疑的
ただ高度なスキルを持った著名人が支持しているのでコード解析の弱体化のデメリット以上に何かしらメリットがあるのだろう
そしてそういった著名人は必ずテストも推奨している
テストを書かない場合は静的言語のほうが有利なのだろう
しかしテスト書けば動的言語の弱点が補われるのでメリットのウェイトが大きくなる
332: 2020/12/25(金)11:49 ID:JfQSa+1c(8/10) AAS
>>327
何もできないというのは間違い
しっかりしたシステムでは必ずクライアント側でもデータ検証を行っている
ただしそれはコード重複や無駄なリモート呼び出しの実装という負債を抱え込むデメリットと常にセット
フロントエンドとバックエンドで言語を揃えれば負債なしにフロントエンドでデータ検証を行うことができる
もちろんデータ検証以外の処理もおなじこと
333(1): 2020/12/25(金)12:16 ID:uurLZNKt(5/8) AAS
>>331
そう。その何かしらのメリットを知りたいのだ…
>>245
>>250
はjavascriptの例だが、これがrubyでも起こるとすると
しょーもないCRUDの画面でもテスト書かないといけないのだろうか。
javascript勢がTypeScriptに流れてるってことは
省1
334: 2020/12/25(金)12:24 ID:cyV6b5qO(1) AAS
それをここで聞いてもな…
親の仇の如く口汚く罵られるだけで、
メリットなんか提示されないと思うぞ
335: 2020/12/25(金)12:30 ID:uurLZNKt(6/8) AAS
だよね…
技術の優劣をつける意図はないんだが、
自分が作るシステムでは正しい技術を選択したいという想い
336: 2020/12/25(金)12:31 ID:fU2xV1RD(1) AAS
>>321
明日もお願いします。
337(2): 2020/12/25(金)12:32 ID:uurLZNKt(7/8) AAS
Webフレームワーク比較検討スレみたいなのがほしい
js系の言語のスレはBlazorの話するとうざがられるし
338: 2020/12/25(金)12:37 ID:JfQSa+1c(9/10) AAS
>>333
動的言語はコード編集から動作確認、テスト実行開始までがとにかく早い
なのでゼロベースの新規プロジェクト、サービス公開までの時間を最優先する場合にはデメリットよりメリットが上回る
339: 2020/12/25(金)13:33 ID:pgbI6Wzr(1/5) AAS
>>337
人気のweb frameworkのスレッドは個別にあるしそこでいい。
全部の言語まとめて扱うと荒れる。
ＪSやJavaのスレッドはある
Java Web Application Framework総合 ver2
2chｽﾚ:tech
C#は乱立してないから素直にASP.NET使えばいい
省2
340(1): 2020/12/25(金)13:37 ID:pgbI6Wzr(2/5) AAS
>>337
うざがられてあたりまえ
JSやってるやつらのほとんどがC#を使えない
C#使えるならバックエンドは迷わなくていいASP.NETでいい
迷うならフロントまわりの技術
341: 2020/12/25(金)13:55 ID:8j4BK9K7(3/3) AAS
自演ぽいな
342: 2020/12/25(金)14:03 ID:l1B2LBGM(1) AAS
そろそろ学習本が欲しいところ
アレ以外で
343(1): 2020/12/25(金)14:22 ID:vv0pxJyE(3/3) AAS
>>330
じゃ、Blazor Serverはリモート実行だから”メソッド共有”じゃないってことね
異なるプログラムで共通のライブラリを使うことを
”メソッド共有”って呼んでもなかなか通じないと思うよ
344: 2020/12/25(金)14:24 ID:JfQSa+1c(10/10) AAS
>>343
ではなんと言ったらわかりやすい？
345(1): 2020/12/25(金)17:26 ID:UA1/tVeu(3/4) AAS
共通するコードをライブラリ化して共有でいいんじゃないの
346: 2020/12/25(金)17:48 ID:tkA/KKSW(1) AAS
バッと来て
グッと溜めて
ブワッ！
347: 2020/12/25(金)18:29 ID:AIeBZh27(1) AAS
>>345
長いので1単語にまとめて
348(1): 2020/12/25(金)19:21 ID:uurLZNKt(8/8) AAS
>>340
そうなんだろうか
実はC#erが食わず嫌いなだけで、実はあちらのほうがめちゃくちゃいいものなのかもしれないよ…？
349(1): 2020/12/25(金)19:30 ID:UA1/tVeu(4/4) AAS
以前は asp.net は Windows Server でしか動かなかったからなぁ
今でこそようやく Linux でもまよもに動くようになって2年ぐらい？
twitter でも .net core で検索すると
一年前はほんと大して結果なかった気がするけど
最近は増えてきてるかな
まだまだこれからでしょ
350: 2020/12/25(金)20:54 ID:pgbI6Wzr(3/5) AAS
>>348
あちらのほうってなんだよ
エンジニアならもっとはっきりかけよ
JSのbackendのweb frameworkか？
ろくなのないって俺が何度も書いてる。試す価値なし。
疑うなら自分で試してベンチマークとかとれよ
RailsもNode backendも遅くてゴミ
省3
351: 2020/12/25(金)20:56 ID:pgbI6Wzr(4/5) AAS
>>349
昔はLinuxでというかライセンス無料で使えなかったのは大きいね。
JSやってるやつらはいまだにIIS, Windowsでしか動かないと思ってる。
あとclassic ASP時代のイメージのままの人も多い
352: 2020/12/25(金)21:08 ID:pgbI6Wzr(5/5) AAS
高速なコードで作りたかったらstaticに限る。
主要OSの主要な言語はstaticだ
Swift, Kotlin, Java
server-sideでKotlinもあり。
353(1): 2020/12/25(金)23:41 ID:Z26lwPgE(2/2) AAS
サーバーとクライアントは同じ言語の方がいいんだろ？
354: 2020/12/26(土)00:06 ID:w6CJ0JU3(1) AAS
>>353
できれば同じ方がいいがパフォーマンスも生産性も低いJSに合わせるのは愚策
server-sideでJS使ってるのはアホだと思う
大手ならserver-sideとclient-sideは別の人材が開発するのだから
言語を合わせるメリットはあまりない
ヤフーとかもbackendでnode.js使ってるが事故ばかり起こしてるだろ
レベルが低い
355(1): 2020/12/26(土)19:37 ID:5ukh9MxR(1/2) AAS
日本人の誰かBlazorのwikiを作ってくれ
フリーでオープンソースのウェブフレームワークって書くだけでも
wikiがないとBlazorが何かわからん
なぜC#を使ってウェブアプリが作れるのか？
ウェブブラウザはC#を解釈しないからJavaScriptとHTMLだろ
356(1): 2020/12/26(土)19:44 ID:T66JFeJq(1) AAS
BlazorWasmのほう？
WebAssemblyで調べたらいいのでは
357: 2020/12/26(土)19:54 ID:5ukh9MxR(2/2) AAS
>>356
WebAssemblyはwikiがあるが本文にBlazorがない
358: 2020/12/26(土)20:13 ID:q2RopqqH(1) AAS
所詮その程度のオモチャということです
359(1): 2020/12/26(土)20:19 ID:zr3CHg45(1) AAS
WebAssemblyはそれようの仮想マシンで動くからじゃないの
C#コードをその中間言語にコンパイルするだけ
たぶん
360(2): 2020/12/27(日)11:16 ID:FLSM18Bj(1/2) AAS
>>355
そんなwiki作っても内容古くなるし意味ない
不正確で古い情報入手してどうする？
英語でMSのドキュメント読みなされ
何度も言うけどBlazorと書くべきじゃない。
Blazor Server, Blazor WebAssemblyで
アーキテクチャが全く違う。
361(1): 2020/12/27(日)11:17 ID:FLSM18Bj(2/2) AAS
>>359
ちがう、いいかげんなこと書かずに
MSのドキュメントを読むべき
362: 2020/12/27(日)11:17 ID:l7B3kP+i(1/2) AAS
>>360
似てるよ。
363(1): 2020/12/27(日)11:44 ID:Y/0KLGYh(1) AAS
>>360
Blazorを初見で見て1分で何か知りたいだけでwikiがいい
時間をかけて英語でMSのドキュメントを読まない
364: 2020/12/27(日)11:56 ID:l7B3kP+i(2/2) AAS
>>363
Web Assembly
画像ﾘﾝｸ[png]:docs.microsoft.com
Blazor Server
画像ﾘﾝｸ[png]:docs.microsoft.com
365: 2020/12/27(日)12:57 ID:5MC+7bSJ(1) AAS
>>361
あーそうね
Ｃ#のコードをいつも通り.NETの中間言語にしたものを配布して
ブラウザでの実行時にwasmのコードに変換して実行だっけ？
大して変わらんと思うけど
366: 2020/12/27(日)14:19 ID:iruxp8RS(1) AAS
.NET6でAOTが入る予定らしいがファイルサイズの問題とかあるしwasm書くような用途なら他の言語の方がいいんじゃね
367: 2020/12/28(月)12:55 ID:Ov8uGTUf(1) AAS
状態管理ってどうやるのが無難なのかな？
blazor + fluxor ？
368: 2020/12/28(月)20:34 ID:N8gr0T4H(1) AAS
状態管理サービスをDI
369: 2020/12/28(月)20:36 ID:RNhofGKy(1) AAS
blazorserver ならセッション？
webassemblyならいる？
370: 2020/12/28(月)23:32 ID:w2tkTAcI(1) AAS
GO + wasm が来年のトレンドだと思いましゅ
371: 2020/12/29(火)01:03 ID:QFieIEDm(1/2) AAS
Kotlinはブーム来てる
Kotlinはwasmもすでに存在するようだ
372(1): 2020/12/29(火)07:55 ID:iWtJxFHh(1) AAS
wasmとserver
wasmの方が人気だよなあ
serverはwebformの移植用以外は使い道がないんだろうか
373: 2020/12/29(火)09:17 ID:8biyF2ED(1) AAS
go + wasm で使えるイケてるフロントエンドフレームワークがあったらいいんだがなぁ。
374: 2020/12/29(火)09:43 ID:QFieIEDm(2/2) AAS
Googleが採用言語を分裂させすぎだから
Goは普及しないだろ
FlutterではDart
AndroidではKotlin推してる
全部Goにしてたら結果は違ったはず
Kotlinのが流行ってるしな
Go速いらしいけど人気ないのははハードル高いんだろうか
375(2): 2020/12/29(火)12:10 ID:TrPJjXJg(1) AAS
>>372
これホント？
なんとかC#しか使えないエンジニアを有効活用して
JSの10倍遅くても問題ないからオフラインでも使えるWebアプリを作りたいってニーズある？
JSが不要になるわけじゃないし現状はデスクトップアプリかblazor serverのほうが何倍も良いと思うけど
376: 2020/12/29(火)12:22 ID:gscEc512(1) AAS
PlayStation Portable go の運命と重なる...
377: 2020/12/29(火)12:30 ID:iAxs8NN4(1) AAS
>>375
どっちでもいいんじゃないの
何倍というほどの差はない
378: 2020/12/29(火)12:33 ID:Fq3XcUlo(1) AAS
>>375
おっしゃるとおり！
俺のような企業向けアプリしか作らない人間からすると
wasmよりserverのほうが使えそうなんだよね
でもblazorでググるとwasmの記事ばかり引っかからない？
あっちのほうが期待されてるように感じる…
379(1): 2020/12/29(火)13:01 ID:k23+wtCh(1/4) AAS
Chromeではある程度可能だが、いまのところ、広く一般には、Wasmは、ローカルファイルシステムになかなか自由にはアクセスできない。
ところが、Cordovaはlocal http serverをアプリ起動時に立ち上げて、
WebViewでHtml+JS+Wasmを起動ですることによって、
Wasm
--> JS
--> XmlHttpRequest()/fetch() で "外部ﾘﾝｸ:localhost:5000機能名?トークン&パラメータ" にアクセス
--> Http プロトコルの Http Request が発生し、local http serverが眠りから覚める。
省10
380: 2020/12/29(火)13:02 ID:EHaGj/ct(1) AAS
そりゃ技術的に面白いのはwasmだから話題になるのそっちだよ
381(1): 2020/12/29(火)13:07 ID:k23+wtCh(2/4) AAS
>>379
[補足]
この方式だと端末内の他のアプリからでも、このアプリのlocal http serverに
アクセスできるからセキュリティー的な問題が有るという心配が有るかもしれないが、
そこは「トークン」をつけているので心配が無い。
それは、アプリ起動時に乱数の様なものから作成し、local http serverとJSの
両方に同じトークン値を渡すことで、鍵の様な働きをする。
省2
382(1): 2020/12/29(火)13:19 ID:k23+wtCh(3/4) AAS
MonacaはCordovaアプリをブラウザから作製できるようにした「クラウドIDE」で
Mac実機無しにiOSアプリを作製してAppStoreに登録できる、とされている。
383: 2020/12/29(火)13:21 ID:k23+wtCh(4/4) AAS
>>382
ただし、クラウドの先にあるMac実機をレンタルする必要があるかもしれない。
384(1): 2020/12/30(水)19:23 ID:+vZt7ZP1(1) AAS
>>381
それＷＥＢアプリであるメリットを感じないんだが
そのトークンはだれが作るって？
ローカルサーバーに自分でトークン作って渡すんなら、トークン偽装しほうだいだな
385: 2020/12/31(木)14:25 ID:hpqEd6nD(1) AAS
>>384
この話は、Html+JS+WasmのWebアプリWを、WebViewを使って、
native アプリAのようにする場合の話。
native アプリAが起動するときに、まずトークンTを作り、
WebViewとHttpServerを同時に起動し、その両方に同じトークンTを
渡す。
nativeアプリA
省14
386(2): 2020/12/31(木)14:45 ID:tdaLm2s5(1) AAS
ネイティブアプリならそのままローカルファイルアクセスしてUIレイヤーとしてWebView使えば十分では？
わざわざローカルでweb server起動してそれ経由でファイルアクセスさせるメリットってあるの？
387(1): 2020/12/31(木)14:52 ID:bz8vpTSU(1) AAS
でも、既 存のア プリの流 用なら単にserverとclientを一箇所で動かすだけに見えるし、
新 規ならそもそもメ リ ットがどこにあるんだろうという感じだし。
どうしてもUIをhtmlとjsで書きたい場合とかかな。
388: 2021/01/01(金)02:03 ID:y/yrEKhd(1/2) AAS
>>386 >>387
自分でクロスプラットフォームツールキットを作っている場合、
iOS/Android/Windows/Linux/Macなどに個別に対応させるのが大変な場合、
HTML+JS+Wasmでまず、ブラウザで動くようにしておき、ファイル入出力
部分だけを上記の様な local HttpServer 方式で行えば便利。
389: 2021/01/01(金)02:09 ID:y/yrEKhd(2/2) AAS
>>386
それだとWasmをメインプログラムとしたクロスプラットフォームアプリは
作りにくい。
Wasmの関数の中にファイル入出力を行いたい部分が有った場合など。
390(1): 2021/01/01(金)13:36 ID:xBl+DmmI(1) AAS
FileとかOS API使いたければ素直にnative appにするほうがいい。
わざわざwasmとか意味不明
391(1): 2021/01/01(金)23:29 ID:TX7qBddY(1) AAS
>>390
特にクロスプラットフォームのライブラリを自作する場合、ブラウザ上のWasmで
ファイルアクセスまで出来れば対応が楽。
上下前次1-新書関写板覧索設栞歴
あと 217 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s