[過去ﾛｸﾞ] 【本命】Blazor スレ1【真打】 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
697(2): デフォルトの名無しさん [sage] 2020/11/08(日)11:52 ID:+pLcijcy(2/2)
>>695
CQRSのCではEFのほうが遥かに洗練されてる
Qでは高速で複雑なSQLを書きたくなる場合が増えてくるのでDapperが有利になる
多くの開発者が複雑化したQのせいでEFは使えないと思い込んでいるがEFはDapperと共存可能だ
更にいうと昔と違ってEFは随分と速くなった
ネイティブSQLもサポートしている
Dapperに頼らなくてもQを上手く実装することができるようなってる
699(1): デフォルトの名無しさん [] 2020/11/08(日)12:11 ID:uTVwuNgX(1/2)
>>697
もう全然Blazor関係ない話で恐縮だけど…
大抵のDBって命名規約がスネークケースだよね。
しかも大文字か小文字のどっちか。
一度モデルファーストで作ったテーブルはキャメルケースで作られるから、生のSQL発行しようとしたらカラムIDを全部ダブルクォーテーションで括る必要があって苦労した苦い思い出がある。
LINQと生SQLどっちも使うとなるとこの問題に引っかかる。
自分のEFの知識が数年まえで止まってるのでいまはいい仕組みがあるのかな。
Dapperはパラメータで勝手にマッピングしてくれるから助かる。
705: デフォルトの名無しさん [sage] 2020/11/08(日)13:11 ID:t+zVbDF+(5/8)
>>695
パフォーマンスの面でDapperは昔は意味あったとおもうけど
いまのEF CoreとASP.NET Coreだとかなり速いからDapper選ぶ意味がほぼないと思う。
EFで満足できない箇所だけピンポイントでダイレクトにSQL使うか、
ストアドプロシージャを使えばいいと思うわ
>>697
たしかにEF Core速くなってるね
あとストレージがSSDになったのも超大きい
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s