sql - インラインSQLを使用するのが悪い場合、LINQを使用してクエリを実行する方法は実際にはどのように異なりますか？

Question

LINQを使用してクエリと操作をインラインで実行することに関する一般的なコンセンサスは何ですか？これは、SQLステートメントをコードに埋め込むこととどのように異なりますか（これはノーノーと見なされます）？

Answer 1

SQLに関連しないLINQの使用をすべて無視し、LINQ-to-SQLを検討します。

LINQクエリはクエリ定義を保持するオブジェクトであり、同等のSQLは、クエリが実際に繰り返された時点でのみインスタンス化されます。これにより、コンポーネントを適切に分離し、クエリが下位層（リポジトリなど）によって返され、スタック上の上位コンポーネントによって変換されるパイプラインスタイルの処理が可能になります。クエリは、最終的に繰り返される最終的なフォームに到達するまで、処理パイプ内の各コンポーネントからの新しいフィルター、結合、およびその他の「アーティファクト」に対応できます。この操作は、ストレートテキストSQLを使用して実際に不可能です。

LINQのもう1つの利点は、データベース以外の開発者にとって、その構文が理解しやすいことです。SQL構文の専門知識は、驚くほど見つけるのが難しい資産です。SQLの微妙なポイントを超えて学習することに時間を費やすことをいとわない開発者はほとんどいません。SELECT * FROM ... WHERE ...。linq構文は、.Netの日常環境に近く、ターゲットのバックエンド（T-SQL、PL-SQL）に適切なSQLを開発者に学習させるのではなく、そのレイヤーにある既存のスキルセット（ラムダ式など）を活用します。等）。linq式が関係代数でほぼまっすぐに目的の結果を表現することを考えると、プロバイダーは適切なSQLを生成する（または実行計画をまっすぐに生成する）ためのはるかに簡単な仕事をします。これを、「一般的な」データベースドライバがSQLテキストで貴重に直面しなければならなかった不可能なタスクと比較してください。ODBCエスケープ構文を覚えていますか？

Answer 2

その通りです。「コードにSQLステートメントを埋め込むことは悪くありません。」ひどいです。

そうすることで、アプリケーションが高度に結合され、脆弱になり、保守が困難になります。少なくとも、すべてがprocにある場合は、何かを変更するときに、依存関係を検索できます。

ストアドプロシージャは、ビジネスロジックを処理しているプロシージャについても削除する必要があると感じています。

その理由は、ビジネスロジックがデータ層ではなくビジネス層に属しているためです。

もちろん、生成されたLinq to SQLが厄介で遅いことが判明した場合は、procを使用する必要があります。

Linq To SQLの大きな利点の1つは、フィルターをチェーンできることです。必要に応じて、ロジックを介して句を動的に追加するだけです。複数のパラメータに基づいてデータのセットを呼び出したいという理由だけで、新しいプロシージャを作成する必要はありません。

Answer 3

コードにSQLステートメントを埋め込むことは悪くありません。それはすべて、あなたがそれらを書いているあなたのアプリケーションのどの層に依存します。

データストアへの読み取りと書き込みに関連するものはすべて、データアクセス層にある必要があります。

Answer 4

「LinqToSql」 と「インラインSQL」（一般的な最悪の場合）の2つの利点。

パラメータは、連結されたテキストとしてだけでなく、パラメータとして扱われます。これにより、SQLインジェクションの問題が解決されます。

個別のモデルレイヤーにより、コンパイル時に、生成されたSQLがスキーマと一致するかどうかを確認できます。（インラインSQLの最悪の場合、たとえば、削除された列を参照していたかどうかをコンパイル時に知る方法はありません）

Answer 5

一つには、LINQステートメントはパラメーター化されています-インラインクエリは必ずしもそうではありません。もう1つは、LINQは基本的にORMレイヤーを作成し、データベースオブジェクトを基本的にコード内のオブジェクトとして扱うことができるようにすることで、コンパイル時のチェックを提供します。一方、インラインクエリは、コンパイル時に壊れないテキストのブロブです...

Answer 6

他の回答を見ると、質問を誤解している可能性があります...しかし、LINQ-to-SQLではなく、C＃のコレクションでの通常のLINQについて話しています。

SQLステートメントをコードに埋め込むと（変数にしたり、SQLをパラメーター化するのではなく）、将来別のデータベースをサポートしたい場合は、自分自身にとってはるかに困難になります。SQLと同じように古く、標準化されていますが、ベンダー間にはまだ多くの非互換性があります。

LINQを使用すると、移植性はもはや問題になりません。コードはC＃で記述され、LINQはC＃です。

Answer 7

私の少しの理解から、LINQ-to-SQLまたは他のORMを使用するか、SQL呼び出しをラップする独自のコードを使用するかにかかわらず、基本的には、SQLについて心配する必要がない抽象化を提供します。

また、私が正しければ、LINQtoSQLはSQLServerのみをサポートします。
LINQ構文を使用してSQLのような方法で条件を作成できると思います。

個人的には、なぜ誰かがLINQtoSQLを使用するのかわかりません。
専門家は私がそれの必要性を理解するのを手伝ってくれますか？

Answer 8

コードのある行で、誰かがSQLを入力するのが適切かどうかを判断することがあります。ただし、その代わりに、LINQを使用します。

したがって、SQLがインライン化されるべきではないのにLINQがインライン化されるべきかどうかは問題ではありません。問題は、データストレージアクセス表現をどこに配置するかです。コードのある行でLINQを記述していて、このスコープが格納されたデータにアクセスできることに不安を感じる場合は、間違った場所です。

LINQは、データ操作の単なる抽象化です。これは、セットをフィルタリングするためのショートカットです。データベースがSQLを理解するのと同じように、.NET環境にはデータと通信するための言語があります。

LINQと、ループ内、ファイル、またはネットワークソケットからのデータに対するifステートメントの実行の違いは何ですか？なし、それは単なる構文です。SELECT * FROM tableすべての行を関数に対してフィルタリングする場合、 where c.SomeProperty < xLINQを使用する場合との違いは何ですか？構文だけです。

確かに、LINQはデータベースから行を返すだけではなく、それ以上のことを認識して実行します。コレクションからオブジェクトをインスタンス化できますが= new ClassName(column1, colum2)、SQLステートメントの結果からもインスタンス化できます。

つまり、コードにインラインSQLを書き込むことがノーノーである場合は、LINQを記述する必要があります。

しかし、これはプロジェクトごとに異なります。データベースは主にSQLを理解しているため、少なくともコード、ライブラリ、または環境のどこかにインラインSQLがあります。

Answer 9

埋め込みSQLを幅広く使用してきましたが、本当の危険は、それがコード生成テクノロジであるということです。Cコード（または任意の言語）を記述してからSQLに切り替えてから、再びCに戻ります。後でコンパイルする前に、先行タスクはコードをすべてCに書き換えます。その結果、非常に紛らわしいエラーメッセージが生成される可能性があります。あなたは、埋め込みSQLがあなたを解放することになっていたデータベースと相互作用するためのAPIを学ぶことを余儀なくされています。最後に、ビジネスルールをクエリに埋め込んでビジネスレイヤーとデータレイヤーを混乱させるリスクがあります。Linqは、これらの問題の一部を回避します。まず、Linqは言語の一部です。構成は、プログラマーが期待するように多かれ少なかれ機能します。いくつかのSQLタイプの構文が含まれていますが、ほとんどの場合、構文はホスト言語（つまり、C＃）に焦点を合わせています。コンパイルチェックは、作成した実際のコードに対して実行されます。したがって、前処理の前にエラーを構文に変換する必要はありません。クエリの結果は、期待どおりにオブジェクトとコレクションになります。ただし、データ層にビジネスロジックが混在する危険性は依然としてあります。さらに、Linqには、問題のフィールドが含まれないことが多いエラーメッセージに関する独自の問題があります。それでも、それはオブジェクトの世界とリレーショナルの世界の間の良い妥協点です。