ふらっと C#,C♯,C＃（初心者用） Part145

2019/10/07(月) 20:16:17.93

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part144
https://mevius.5ch.net/test/read.cgi/tech/1563258983/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2019/11/09(土) 16:58:20.97

>>510
ランタイム同梱でexeを配布できるから問題ない

2019/11/09(土) 17:06:05.75

不要な引数は_だね
破棄パターンはまだ言語仕様になってないけど要望も多いし議論も進んでるからそう遠くない未来には入るだろう
すでに導入されてる言語もあるし

俺個人的には526のbみたいなlistなのかarrayなのかよくわからん制御のほうが混乱する

2019/11/09(土) 17:12:48.50

>>526
>(b)
>var list = new List<Label>(100);
>for (int i = 0; i < list.Count; i++) list[i] = new Label();

list.Countは0なのでループの中身は実行されない
一瞬で何やってるか理解できてる・・・？

2019/11/09(土) 17:20:28.60

>>526

LINQ が万能ではないことは認める。使う人を選ぶ技術でもあるし。

だが、Enumeration の操作にいちいちカウンタ使って境界テストしなければならなかったり、if, break, continue でフローを追わなければならなかったりするのは、レビュアーや運用・保守者を泣かせるコードになることが多い。

モダンな言語がここ10年のあいだに参照透過性や関数型を追求する方向に進化しているのは、そういう可読性、保守性、開発効率性を意識しているから。

ちっちゃいコードなら手続型で好きなように書けばいいんだよ。大規模開発やビジネスロジックが重要な場面では関数型で書くのが適してる。

まあ、LINQ もあまりやりすぎると読みにくくなるのだが。

2019/11/09(土) 17:41:21.17

>>533
aをrootノードとしたツリーとして対象をとらえれば
習ったことを生かせるんじゃないの？

2019/11/09(土) 17:42:32.31

>>537
ほんとだ引数capacityじゃん
Linq使っててよかった

2019/11/09(土) 17:47:37.52

>>537
ぐぬぬw

2019/11/09(土) 17:53:51.45

良いコントだったよ

2019/11/09(土) 18:17:38.87

わろたｗｗｗ

2019/11/09(土) 18:25:40.87

MSのDocs(?)の日本語版ってマウスオーバーでオリジナルの英語版が読めなかったっけ？
対応してるページと対応してないページが混在してるのか？
Docsって何やねんw

2019/11/09(土) 19:22:51.64

>>534
凄い……いや理解するのに10分以上かかったけど確かにこれで出来てる……
ありがとうございました勉強になりました

**デフォルトの名無しさん** (JP 0Hcf-ApVS) · 2019/11/09(土) 20:24:40.88

おまえら天才か

2019/11/09(土) 20:45:25.24

LINQは慣れると意図が読めるけど
forは何のためにループ回してるのかは解りづらくなりがち

数学的な問題や複雑な処理を書く場合LINQの表現力はすごいけど、慣れてない人が理解できるようになるのは大変

LINQやRxなしで同等のコード書くのはもはや考えられない

2019/11/09(土) 20:48:12.46

プログラマなら普通は逆だよね？

linqというかSQLはただの集合論のはずなのになぜかforの代替で使われたりする
linqはループを隠ぺいしているだけで実際はループしてる

2019/11/09(土) 20:50:43.28

Linqが本当に集合論を表してるなら途中でエラーがでてもデフォルトで残りの処理を終えるはず
そしてエラー含んだ集合が手元に残るはず

2019/11/09(土) 21:03:01.43

>>547
> forは何のためにループ回してるのかは解りづらくなりがち
流石に
> for (int i = 0; i < list.Count; i++) list[i] = new Label();
の意図がわからないならプログラマーやめるべきだと思うわ

2019/11/09(土) 21:05:00.70

やりたいことは何かを書いてそれを実現する具体的な方法をライブラリにお任せするのがLinq(宣言的)
やりたいことは何か全くわからないけどそれを実現する具体的な手続きだけは知りたくないことまで細かく書くのがループ(手続き的)

何をしたいのかわからないコードよりしたいことが書いてあるコードのほうが親切

2019/11/09(土) 21:06:24.76

>>549
例外で全部ぶった切ってもいいじゃん
決め事の話だからどっちも筋は通ってる

2019/11/09(土) 21:13:08.77

基本LINQでいいかなってなる
List.ForEachは使わんが

2019/11/09(土) 21:16:52.79

>>550
そらそうだな
こんなコード書いて仕事になるやつおらんやろ

>>551
そうそうそれが言いたかった

2019/11/09(土) 21:22:32.05

>>554
そりゃこんなコード「だけ」じゃ仕事にならんけど、仕事でその手のコードを書くことはあるだろ

2019/11/09(土) 21:32:36.03

大体の場合においてやりたいことだけをlinqで書けはしない
普通の処理をすべてLinqに置き換えられるならそれだけでいいが
そんな世界どこにもない

実現不可能な話でlinqがいいなんて現実的じゃない

2019/11/09(土) 21:34:38.32

標準で書けたところでそれって本当に効率的なのか疑問な場合がある
ループなら一回でmax min両方とれる
linqで標準で書いたとしてMAX　MIN二回ループが回る

2019/11/09(土) 21:40:24.07

基準はシンプル
状態の更新を伴うものはループで書く

2019/11/09(土) 21:45:51.67

プログラマがヘボでクエリとコマンドの分割がうまくできてないとLinqが綺麗に適用できないことがある
しかしLinqはクエリであることを忘れてはいけない
コマンドで汚染されたループをLinqでは書きにくいと主張するより先にリファクタリングすることをおすすめする

速度最適化が必要な場面はあるが常に速度最適化が求められるわけではない
速度よりメンテナンス性が重視されることの方が多い

2019/11/09(土) 21:46:24.40

本当に集合論ならループの順番などという概念がない
が実際にはある
MS自体はシーケンス（連続、並び）と言ってるが一部のオタが勝手にSQLと同じ集合論だと言ってるだけ

2019/11/09(土) 21:48:01.22

どちらとも使えるのが正しい姿で必要に応じて使い分けるのが筋

所がlinq信者は全部lnqでいいforは使わなくていいと言う

2019/11/09(土) 21:55:50.65

Linqでももともとやりたいことをそのまま表現できるパターンは少ない
それでどちらにしてもコードに落とし込みをする段階がある

処理に応じて手順を分解してコードにする
実際にそれをやるのがプログラムである
手順が分解できない、他人の書いた手順を理解する気がないならプログラムする気がないと言うこと

2019/11/09(土) 22:00:36.64

信者うんぬんの前に正しいスペル・大文字小文字でLINQと書けない人がテクニカルなことを主張しても説得力ががが

2019/11/09(土) 22:01:50.43

説得力などなくていいよ
酒飲んでごろ寝してスマホでかいてるんだから適当だよ

2019/11/09(土) 22:05:04.49

ああこれwintabだわ
つかいにくなこれｗ

2019/11/09(土) 22:38:55.83

>>534
これもイテレーター使った方が読みやすい気がする
IEnumerable<string> ReadFilePathsRecursive(string path)
{
　　yield return path;
　　foreach (var path2 in ReadFilePaths(path))
　　　　foreach (var path3 in ReadFilePathsRecursive(path2))
　　　　　　yield return path3;
　　}
}

2019/11/09(土) 23:36:14.18

循環する可能性を考慮しないのって普通にヤバイと思う

2019/11/10(日) 00:04:25.73

俺社環で{}省略していると糞扱いされるので迷わずLinq選ぶわ

2019/11/10(日) 00:18:01.25

>>561
LINQ をまともに使っている人は LINQ の得手不得手を知っているから LINQ が万能だとは言っていない。
データ処理の多くの場面ではカウンタ使ってプリミティブに手続書くのは非効率だと言っているだけ。

逆に手続型信者 (老害ともいう) は不必要な場面でもカウンタ使ってイテレーションを書き、コードをいたずらに冗長化するねっていうこと。それに対する有効な反論がない。自分にとっては読みにくいっていう個人的感想ばかりじゃないか。

誰かが言ったとおりこれは慣れだよ。初めは確かにとっつきにくいが慣れる。そして戻れなくなる。

>>562
趣味グラマーならそれでいいよ。だが、ビッグデータやデータサイエンティストの時代になって業務ユーザもコード読むようになったこのご時世。
運用が止まって、下手くそなコード読んでトラブルシュートしなければならない身にもなってみて欲しい。センスない奴が書いたプリミティブな手続をダンプしながらフロー追っかけて修正し、リグレッションテストして、一定時間内に通常運用に戻すのは地獄。

無意味な宗教戦争にしないために、みなさんが前提や目的や利用場面をもう少し明確にすることを提案する。
下請けで隠蔽工程のコーディング担っているプログラマは LINQ のありがたみなんてわからなくても当然。レビュアーや PM や使う人のことを考えず、自分のスキルでとりあえず動くものを行数書いて月給もらえればいいんだから。

2019/11/10(日) 00:23:11.55

ＬＩＮＱでＤＢ通信タイミングコントロールできなくなって
泣きを見る話は聞いたが

2019/11/10(日) 01:00:17.48

>>570

LINQ to Entities のことかな？
LINQ to Entities は残念ながらまだ発展途上だね。(もう 10 年にもなるのに。)
業務ロジックも書けなくはないが、.NET プラットホームや DB 実装などへの依存性が強すぎて、かなり工夫する必要があり、汎用性がなくなってしまう。
Select, Where (, OrderBy, Take, FirstOrDefault, Join)くらいしかまともに使えないと思っていた方が無難だと思う。となると DB アクセス回数と無駄なデータ取得が増えることになり、性能が出ない。

また C# 9 あたりで予定されている Records がないとデータ変換ロジックが非常に書きにくい。

.NET 5 になれば期待できるのではないかと思うけど。

2019/11/10(日) 01:09:03.51

>>557
おっしゃる通り、LINQ は Reduce 系処理の効率性がよくない。そこは工夫する必要あり。

ただ、Aggregate を使えば、一回の走査で Max, Min 両方同時に取れると思うよ。

2019/11/10(日) 12:04:37.46

>>550
やめた方がいいよ

2019/11/10(日) 12:51:05.83

いいからアプリ作れよ初心者

2019/11/10(日) 14:15:34.99

標準のLINQでは効率的に処理できないなら
効率的に処理できる拡張メソッドを定義してそれを使うべき

流れの中でforやらforeachを使われると可読性が落ちるしテストもしにくくなる

2019/11/10(日) 14:48:47.97

そういうオナニーされるとそれこそ読みづらい
フレームワーク作ってるんでない限り、チーム開発で拡張メソッドを自作するのは本当にやめてくれ

2019/11/10(日) 15:27:29.24

開発組織のコード管理能力やチームメンバーのリテラシーに合わせて判断することだとは思うが
拡張メソッド作れないって縛りプレイはできれば勘弁して欲しいな

2019/11/10(日) 15:45:16.03

拡張メソッド無しはさすがにしんどい
そら上位のnamespaceにstringやらintのextension大量に作るとかやられるのは勘弁してほしいがちゃんと整理されてるなら問題ないじゃん

2019/11/10(日) 16:04:31.99

拡張メソッドを使わないというオナニーではないのだろうか。

2019/11/10(日) 19:59:11.47

Linqの構文を本家のSQLに逆輸入すれば良いのに

2019/11/10(日) 23:41:53.75

そういや、Max、Min句が対象とした個別要素を返すってのは酷い気がするな
IEnumerable<T>に対して使った時にT型で返すように何故しなかったのか全く理解できん

2019/11/11(月) 00:31:18.41

多少非効率でもなるべくもともと用意されてる機能や関数を使うのが分かりやすい派です

2019/11/11(月) 02:22:50.36

MoreLINQ使えばMinBy/MaxByがある
(複数返すからTじゃなくIEnumerable<T>的なのが返される)

リスト埋めるやつもMoreLINQ使えば比較的読みやすい
var labels = new List<Label>().Pad(10, _ => new Label());

2019/11/11(月) 06:43:42.02

>>581
そりゃ欲しいのは最大値や最小値なのに複数の要素が返ってきても面倒なだけだし

2019/11/11(月) 08:24:51.18

>>584
ま、その通りなんだけど、581 が言いたかったのは、該当要素 T を返す拡張があってもいいよね、インデックス付き Select とかあるんだからさ、ってことでは？

>>583
有益な情報ありがとう。

2019/11/11(月) 09:41:13.10

>>585
そういう拡張があってもいいなと言うならわかるが
> Max、Min句が対象とした個別要素を返すってのは酷い気がするな
と言うのは思慮が浅すぎ

2019/11/11(月) 12:40:24.59

generics, trait だろ。
has-a, interface, duck typing など、継承じゃなくて包含

Ruby では、<=> 宇宙船演算子があれば比較できる。Comparable

2019/11/11(月) 12:41:25.30

どうかな
個人的にはどちらか一つだけしか選べないとしたら>>581の実装の方が合理的だと思うけど

単純にそっちの方が需要多いと思うし、二度手間にはなるが現状の実装は
>>581的実装で代替できる（変換結果の最大値は変換関数から求められる）のに対して
逆はどうやっても不可能だから

2019/11/11(月) 12:47:13.66

>>588
上位互換の方がいいっていうのはわかる。でもそれは LINQ to Object だけを考えた場合ね。

LINQ は LINQ to Entities という OR マッパーも強く意識しているから、標準 SQL 互換の機能も大事であり、どちらか一つという選択を強いるなら現状になる。

2019/11/11(月) 12:47:47.01

別に難しいもんじゃないんだし作りゃいいんだよ
どういうのがベストかが状況によってたやすく変化する処理だと思う
値が欲しいのか要素が欲しいのか、一つで良いのか全部列挙するのか
だから標準としては1回走査で済んでsum等の算術系と同じような入出力になる現仕様を選んだんじゃない？

2019/11/11(月) 18:08:06.42

なんかよくわからないけど、SQLとの互換性ならTが返ってきた方が遥かにSQLに近いでしょ

2019/11/11(月) 18:48:51.85

？？SQLで集計関数使ったら元のレコードはわからんめえ

2019/11/11(月) 18:53:21.43

>>591
わからないなら無理に噛み付かなくていいから。
LINQ to Entities の設計思想と実際の実装がどうなってるのかある程度理解できるようになってから出直して。

2019/11/11(月) 18:57:02.20

Tを返すと戻り値がIEnumerable<T>になる
流石にそれをMax関数と呼ぶのは抵抗がある

2019/11/11(月) 19:00:34.90

まず最大値を取る
その値を持つ要素の集合をselectする

確かに無駄だな
SQLはどこかで最適化してるのかな？

2019/11/11(月) 19:02:33.34

MAXはMAXだけどそういう用途の関数？があってもいいかもね
というかすでにあるんだろうか？

2019/11/11(月) 19:42:55.85

>>596
標準ではない
使ったこと無いけど583が紹介してるものか自作するか
自作しても数行だしググればコードは転がってるよ

個人的にはこういうやつは上げだすとキリがないんで現状で十分かなと思ってる
標準で山ほど用意されても何があって何を自作しなきゃならんかがわからなくなるんで本当に基本的なものだけあればいいかなと思う

2019/11/11(月) 19:55:30.29

LINQじゃなかったら作るのは簡単

2019/11/11(月) 20:48:49.06

SQLで書けるものはだいたい書けるようなってないと使いづらいよやっぱ

2019/11/11(月) 20:52:24.25

SQLだとストアドあるけど、LINQで書けるの？
インラインビューとかも

2019/11/11(月) 20:54:23.36

それは流石にLinqのせいじゃなく、例の変な人が言ってるフレームワーク等で吸収する部分じゃないか？

2019/11/11(月) 21:13:49.74

>>595
SQLの場合はインデックスがあるから一般的にO(log n)で最大値のキーが取得できる

LINQ標準でMaxByと同じことをやる場合はちょっと効率悪いけどOrderBy使う
O(n)にするためだけにAggregate使った拡張メソッド作るよりも
走査する件数を減らすことを考えたほうがよかったりする

2019/11/11(月) 21:39:19.76

LinqとSqlは根本的に別物なので使い分けろ
当たり前のことだな

2019/11/11(月) 21:40:04.42

>>600
DDLもLINQで書けるようにしろとか言いそうな勢いだなw

2019/11/11(月) 21:46:03.84

出来ればやってくる欲しいけどw

2019/11/11(月) 21:51:17.93

>>602
LINQ to Object vs LINQ to Entities でインデックスの有無は大きいよね。テーブルごとに特性とサイズを考えて、AsEnumerable でやるか AsQueryable でやるか機能配置の決め手になることがある。

OrderBy 使っていいなら、こんな感じかな？

public static IEnumerable<T> MaxBy<T>(this IEnumerable<T> src, Func<T, IComparable> selector) =>
src.GroupBy( selector ).OrderByDescending( x => x.Key ).Take(1).SelectMany( x => x );

>>600, 601
ストアドは DB の機能だから、フレームワークでは実現できないよ。
フレームワーク側でエミュレートできたとしても DB との間で通信が頻繁に発生することになるから、性能が出ないと思われる。

DB のストアドを呼ぶことはできるはず。

2019/11/11(月) 21:59:36.96

>>604,605
つEFのCodeFirst

2019/11/11(月) 22:10:23.25

>>607
LINQじゃねーしw

2019/11/11(月) 22:38:21.34

>>608
横からすまん。
Code First で DDL 相当のことが「かなり便利に」できるわけだが、DDL やるのに LINQ でなければならない理由を教えてほしい。

2019/11/11(月) 22:50:03.30

>>609
初めからLINQの話してて、何がベストかなんて話してない

2019/11/11(月) 23:03:24.65

LINQって便利なんだけど今一歩物足りないよな
何が足りないのかと言われても難しいが

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-y5kd) · 2019/11/11(月) 23:09:21.20

十分もの足りるよ

**デフォルトの名無しさん** (JP 0Hcf-ApVS) · 2019/11/12(火) 01:07:27.57

前処理はストアドで定義してアプリはストアド叩くのが定石やろ

2019/11/12(火) 02:21:22.46

LANが10Mだったころの定石だな

**デフォルトの名無しさん** (JP 0Hcf-ApVS) · 2019/11/12(火) 03:26:22.31

今は前処理クライアントでやるもんなん？

2019/11/12(火) 06:42:14.04

>>610
LINQ にこだわるなら、こだわるだけの理由が必要。
スレに貢献している人を茶化すなら、茶化すだけの知識なり、思想なり、技術的裏付けが必要。

>>611,612
どちらの意見もわかる。

LINQ to Object に閉じるなら十分。足りない部分はライブラリ自作すればいいし、そのパズルが楽しかったりする。

でも、LINQ to Entities に踏み込むと足りないことだらけ。本質的ではないところで相当な工夫が必要だし、工夫しすぎると汎用性がなくなって使い物にならなくなる。

LINQ to Object で組み始めたロジックを LINQ to Entities 互換に拡張することを考えている時間が結局ムダになることも多い。

両者、似ているようでギャップがかなり大きいところに物足りなさを感じる。

2019/11/12(火) 06:51:40.24

最初から全くの別物なのに似ているというだけで変な期待をかけて勝手に裏切られた気持ちになる人が少なからず居る
別物と割り切って名前もインターフェースも変えれば初学者が迷わずに済んだだろうな

2019/11/12(火) 07:47:36.42

>>617
そうだね。裏切られたとは思わないけど、当初の期待はかなり高かった。

でも、LINQ to Entities の情報が少なすぎて別物だって理解するまでに相当な時間がかかってしまう。
誰も頼れる人がいない中、ネット情報のみの独学でみっちり3週間かかったよ、まともに使えるようになるまでに。

2019/11/12(火) 07:51:50.22

EntityFrameworkなのかEntityFramework Coreなのかはっきりさせとけよ…

2019/11/12(火) 08:11:27.68

>>619
わからなかったからどちらも試したよ。
Framework のバージョンによって作法が大きく異なるのに、ネットはバージョンを示さず情報が混在しているのも混乱する大きな要因だった。

2019/11/12(火) 08:13:15.74

あ、ID 変わっちゃった。
618=620

2019/11/12(火) 10:46:47.47

>>620
一次リソース見なよ

2019/11/12(火) 10:52:36.27

>>622
当然見てるよ。原文で。

2019/11/12(火) 11:56:05.18

まともに使えないものがまともに使えるようになったと言ってる時点でまともな人間でないのは明白

2019/11/12(火) 12:00:35.23

>>623
なら混乱しないはず

2019/11/12(火) 12:08:55.50

>>624
君は読解力ないのかな？
局面によっては使えるかもしれないけど、業務ロジックを完結させるには役者不足、LINQ to Entities はまだまだ発展途上だね、今後に期待、と一貫して言っているのだが。

一次ソースも二次ソースも充実してないのは発展途上でこれからもまだまだ移りゆくものだからだとも思ってる。それがわかるのにけっこうコストがかかったよ、そのあたりが個人的に物足りなさを感じるところかな。

2019/11/12(火) 12:15:05.01

あぁなるほど
データアクセスに業務ロジックをバリバリ書いてしまうタイプの人か

2019/11/12(火) 12:31:28.37

>>625
一次ソースはバージョンに関しては混乱しない。それは二次ソースの話。一次ソースが混乱させるのは、LINQ to Object から Entities へ移行するにあたって、重要かつ基礎的なコンセプトをまともに解説していないこと。

たとえば、IEnumerable の派生である IQueryable はアップキャストするだけで AsEnumerable で評価されてしまうとか、引数となるラムダ式が全く同じ記法なのに IEnumerable では Func で IQueryable では Expression だとか。

これらは分かってしまえば当たり前だし、うまく設計したものだなと感心するけれど、初学者にはトラップでしかない。

君はこれら暗黙の前提を一次ソースで知ったのか？
だとしたらどこにガイドがあるか教えてほしい。

一次ソースに当たれというのは一般的なお約束だけれども、LINQ to Entities に関しては、コンセプトや実装の難しさに比して一次ソースがかなり脆弱で不親切だと思うよ。

617 の言うとおり Object と Entities でインターフェースを変えて設計するか、あるいは、移行に十分な情報を一次ソースが用意するか、どちらかだと思う。そのどちらでもないことがアンチを生んでいる原因ではないかと。

2019/11/12(火) 12:34:30.29

>>627
もちろんレイヤー化はするし、機能配置はしっかり設計するよ。
ユーザーはコード見なくていいって時代じゃないんでね。

2019/11/12(火) 12:56:06.79

真っ赤なガイジ一歩手前

2019/11/12(火) 13:00:05.39

ごめんガイジに触っちゃっま

2019/11/12(火) 13:53:14.21

>>630,631
業務ユーザが LINQ to Entities に手を突っ込むの、ガイジだよなぁ、わかるぞ。
だがね、人のやらないことを先鞭をつけてやらねばならない場合もあるのだよ。

ひととおり技術評価した結果、本格的に導入するのは時期尚早という判断で別の技術つかうことにした。.NET 5 以降に期待してる。

2019/11/12(火) 17:44:24.07

え、業務アプリで普通にLINQ to Entities使ってるけどなんかマズい問題でもあるの？
単純に手軽で使いやすいと思ったから使ってるんだけど・・・・

2019/11/12(火) 17:50:33.05

>>633
問題ない。Dapper開発元のStackOverflowでさえEntityFramework Coreを併用してる。