LinqからSQLコードへの.Net Coreへの移行
Linq to SQLをORMとして使用するレガシーコードがいくつかあります。このロジックを.Net Coreに移行して、Linuxサーバーに格納できるようにします。私の知る限り、L2Sは.Net Coreに含まれていません。
最も抵抗の少ない移行パスは何ですか？
EFがスキップとテイクを使用して大きな結果をチャンクとしてフェッチするのが効率的でないためにL2Sを使用した場合、最善の策は Dapper です。 LINQPad のコピーを自分で取得し、それを使用して各LINQ式に対して生成されたSQLを取得します。
L2Sは、SQLの行番号関数を使用してスキップとテイクを実装するために、実際のクエリの周りに奇妙なSQLをラップします。 SQL Serverの最新バージョンを使用している場合、TSQLにはスキップとテイクに相当する句があるため、これは必要ありません。これは、SQLを直接記述していて、フォローしている人にWTFを引き起こさない包括的なSQLを生成する場合に便利ですが、LINQの方法はSQL Serverのすべてのバージョンで機能します。
次に、このSQLをDapperで使用します。これにより、ORM部分が実行されます。また、L2Sと同様の型マッピングパラメータを適切にサポートしているため、SQL文字列の作成やインジェクションの脆弱性を回避できます。
コレクションメンバーシップによって暗示されるFK値でオブジェクトグラフを作成するためのすべてのスマート機能が必要な場合は、運が悪ければ、手動でコーディングする必要があります。
更新2018-05-11
EFは以前ほど恐ろしくありません。 EF Coreは、EFよりもシンプルでありながら、多くの利点を保持しています。私は現在、作業中のプロジェクトでEF Coreを使用しています。これは、EFがかつて経験したような災害ではありません。
私は外部結合を手伝わなければなりませんでした。 LINQは独自のデバイスに任せて、内部部分をフェッチし、各内部行に対してその外部部分に対して個別のクエリを実行しました。
これをexplicitly内部部分をフェッチし、キーセットをintの配列として構築することで修正しました。別のLINQステートメントは、_Array.Contains_がインデックスを使用するINにマップするという事実を利用して、外側の行のallをフェッチしました。次に、ToArray()を使用して両方の部分を具体化し、LINQを使用してそれらをメモリに結合しました。これにより、実行時間が10分から300msに短縮されました。
これを行う必要はありません。 L2Sはそもそもそれを作り上げていなかっただろう。しかし、少なくとも簡単な一般的な解決策があります。
私のソリューションの欠点は、プログレッシブフェッチにうまく適合していないことです。
DevArtのLinqConnectは、2017年5月の時点で.NET Coreをサポートしています。
https://www.devart.com/news/2017/net-core-support.html
これは、Linq To Sqlの代わりとなるものであり、必要に応じてMS SQL Serverから離れてしまいます！
レガシーコードを.NET Coreに書き換える場合、これにはある程度の努力が必要です。
また、L2Sの場合は、Entity Framework Coreを使用して、これを最新のクエリに書き直す必要があります。ただし、データベースからエンティティを簡単に生成できる場合があります。 モデルのリバースエンジニアリング を参照してください。
これが推奨される方法ですが、あなたの場合、それが最も簡単な方法かどうかはわかりません。