LINQ to SQLの利点は何ですか？
中規模のプロジェクトでLINQto SQLの使用を開始したばかりであり、L2Sが提供する利点についての理解を深めたいと思います。
私が見ている欠点の1つは、コードの別のレイヤーが追加されることです。私の理解では、ストアドプロシージャやADO.Netを使用するよりもパフォーマンスが遅くなります。また、特により複雑なクエリの場合、デバッグが課題になる可能性があり、いずれにせよこれらがストアドプロシージャに移動される可能性があるようです。
より良い開発環境でクエリを作成する方法を常に望んでいましたが、L2Sクエリは私が探していたソリューションですか？または、SQLの上に別のレイヤーを作成したばかりで、2倍の心配がありますか？
L2Sが提供する利点：
- SQLクエリのようなマジックストリングはありません
- インテリセンス
- データベース変更時のコンパイルチェック
- より迅速な開発
- 作業単位パターン（コンテキスト）
- 使用可能な小さなプロジェクトである自動生成されたドメインオブジェクト
- 遅延読み込み。
- Linqクエリ/ラムダの記述を学ぶことは.NET開発者にとって必見です。
パフォーマンスに関して：
- ほとんどの場合、ほとんどのソリューションでパフォーマンスが問題になることはありません。事前に最適化することはアンチパターンです。後でアプリケーションの一部の領域が遅くなることがわかった場合は、これらの部分を分析でき、場合によっては、一部のlinqクエリをストアドプロシージャまたはADO.NETと交換することもできます。
- 多くの場合、遅延読み込み機能はパフォーマンスを高速化するか、少なくともコードを大幅に簡素化できます。
デバッグに関して：
- 私の意見では、Linq2Sqlのデバッグは、ストアドプロシージャとADO.NETの両方よりもはるかに簡単です。 Linq2Sql Debug Visualizer を確認することをお勧めします。これにより、クエリを確認したり、デバッグ時に結果を確認するために実行をトリガーしたりすることもできます。
- すべてのSQLクエリをコンソールウィンドウに書き込むようにコンテキストを構成することもできます。詳細情報 ここ
別のレイヤーについて：
- Linq2Sqlは別のレイヤーと見なすことができますが、これは純粋なデータアクセスレイヤーです。ストアドプロシージャもコードの別のレイヤーであり、ビジネスロジックの一部がストアドプロシージャに実装されている場合が多くあります。これは私の意見でははるかに悪いです。なぜなら、ビジネスレイヤーを2つの場所に分割しているため、開発者がビジネスドメインを明確に把握するのが難しくなるからです。
ほんの少しの簡単な考え。
一般的にLINQ
- 同じ構文と演算子を使用して、メモリ内のコレクションとプロセス外のデータストアをクエリします
- 宣言型のスタイルはクエリに非常に適しています-非常に多くの場合、読み取りと書き込みの両方が簡単です
- きちんとした言語統合により、新しいプロバイダー（インプロセスとアウトプロセスの両方）を記述し、同じクエリ式構文を利用できます。
LINQ to SQL（または他のデータベースLINQ）
- ストアドプロシージャとしてではなく、必要な場所にクエリを作成すると、開発が大幅に高速化されます。必要なデータを取得するためだけに必要な手順がはるかに少なくなります。
- タイプミスがイライラする可能性のある場所に関係する文字列（ストアドプロシージャ、パラメータ名、または単なるSQL）ははるかに少なくなります。このコインの反対側は、クエリに対してIntellisenseを取得することです。
- ADO.NETからの「生の」データを操作する場合を除いて、とにかくどこかにオブジェクトモデルがあります。 LINQ to SQLに処理させてみませんか？クエリを実行してオブジェクトを取得し、すぐに使用できるようにするのが好きです。
- パフォーマンスは良好であると思いますが、そうでない場合は、自分で調整するか、ストレートSQLにフォールバックできます。 ORMを使用しても、適切なインデックスなどを作成する必要がなくなるわけではありません。通常、生成されているSQLで重要なクエリを確認する必要があります。
これは決して万能薬ではありませんが、SQLクエリを直接作成するか、ストアドプロシージャを使用するよりも、非常に好んで使用しています。
更新と同様に、LINQ toSQLの将来に関するリンクを次に示します。
MicrosoftはLINQ to SQLのサポート終了に対するスタンスを確認しましたか？
最後のリンクのコメントが述べているように、LINQ to SQLはなくなることはなく、少なくともMicrosoftによって「改善」されただけではありません。これらのコメントや投稿は、開発計画に注意してください。
私は彼らがあなたが探していたものであると言わなければなりません。慣れるまでには少し時間がかかりますが、一度慣れると（少なくとも私にとっては）戻ることは考えられません。 linqとストアドプロシージャに関しては、ビルドを間違えるとパフォーマンスが低下する可能性があります。ひどくコーディングされたクライアントのいくつかのストアドプロシージャをSQLに変換するためにlinqに移動したため、時間が20秒（Webアプリではまったく受け入れられない）から1秒未満に短縮されました。そして、ストアドプロシージャソリューションよりもはるかに少ないコードです。
更新1：また、取得するものの列を制限でき、実際にはそれのみを取得するため、多くの柔軟性が得られます。ストアドプロシージャソリューションでは、基になるクエリが同じであっても、取得する列セットごとにプロシージャを定義する必要があります。
最近、EntityFramework環境ではLINQ2Entityに切り替えました。以前は、基本的なSQLアダプターがありました。使用しているデータベースはかなり小さいため、LINQのパフォーマンスについてコメントすることはできません。
ただし、クエリの記述がはるかに簡単になり、エンティティを追加することで強い型付けが可能になることを認めなければなりません。