私は少数派のようですが、正直なところ、私は linq に慣れておらず、個人的な開発に何のメリットもありません (メリットがないというわけではなく、私の状況に基づく個人的な意見です)。
私は Web アプリケーション (.net、.net mvc) を構築しており、データ レイヤーの一部をストアド プロシージャに配置するのが大好きです。sprocs について私が気に入っている点の 1 つは、db 全体を生成してスクリプトを作成し、クエリをスキャンして、追加する可能性のある読み取り可能なクエリを高レベルでスキャンできることです。
linq が嫌いな人は、その理由を教えてください。単に知識/学習曲線が不足しているだけなのか、それとも使用しないビジネス ケースがあるのか?
私は実際にLinqを使用していますが、SQLのクエリには使用していません。たとえば、データテーブルの最大値を見つけるために、データテーブルをクエリする非常に簡単な方法として使用します。以前は、このコードに for ループを使用していましたが、Linq を使用すると、コードがより簡潔になり、意図が明確になります。
Linq が汎用の .NET クエリ言語であることを理解すると、その能力と有用性がより明確になります。
では、C# コードでコレクションを処理することはありませんか? コレクション内の最大値を見つけたり、フィルタリングしたり、グループ化したりしますか? 私はこれらをかなり頻繁に行うことを知っています。LINQ を使用すると、非常に読みやすく、宣言的な方法でこれを実行できます (SQL、IMO よりも読みやすく、クエリの順序がより論理的です)。
同様に、LINQ to XML で XML をクエリし、LINQ to DataSet でデータセットをクエリします。ああ、PLINQ による並列化を忘れないでください。
LINQ を愛する理由はたくさんあります :)
最近、LINQ とストアド プロシージャのどちらを使用するかについての有益な議論がありました。これには、それぞれのアプローチの長所と短所が含まれています。
また、LINQ to SQL の将来について懸念している人もいます。
まだ 2.0 であり、新しいバージョンへのアップグレードが許可されていないため、まだ Linq を使用できていません。
元の投稿者は、Linq (クエリのラムダ式) と DLinq (軽量データベースの Linq) を混同しているため、コミュニティではほぼ同義語として使用されています。
Linq は任意のコレクションで使用でき、Sql のような構文を使用できます。そのかなりきれい。
はい、DLinq を使用してストアド プロシージャを実行できます。以下のリンクを参照してください
-RVZ
配列またはジェネリック リストのクエリに LINQ を使用しています。非常に読みやすく、foreach複数のリストを参照する場合でも for ループを入力する手間が省けます。
私は実際に必要がなかったので、まだLINQを気にしていません。
何年にもわたって、私は「オンデマンドで学ぶ」ことを学びました。新しい技術は非常に速く出入りするため、最新のトレンドを研究するのに多くの時間を無駄にすることができます。
LINQ はうまく取り入れられているように見えるので、そうすることを示唆しているわけではありませんが、私の設計が健全である限り、「古い方法」でコーディングすることで眠りを失うことはありません。
現在、Windows XP Embedded 用のソフトウェアを作成しています。私は linq を使用していくつかのスパイクを実行しましたが、現在 XP 組み込みは .Net 3.0 以下しかサポートしていないため、取り除かなければなりませんでした。大した作業ではありませんでしたが、私のコードは、Linq を使用しない場合よりもはるかに見栄えがよくなりました。
Linq to SQL はまだ使用していません。私は Linq to NHibernate ベータ版を試しましたが、準備ができたら、データベースで何かをやり直さなければならないときに、間違いなく私の行くべき道です。
私はLINQが好きです。読み書きが簡単です。SQL クエリの最適化について心配する必要はありません。よりクールな遅延操作です。すばらしい IQueryable を返すことができます。
私が働いている会社には、Linq (to SQL) を使用しないビジネス ケースが 1 つあります。
再コンパイルや再インストールなどを必要とせずに展開後に変更できるため、ストアド プロシージャが好まれます。
個人的には、この議論はあまり好きではありません。非常に多くの人が顧客サイトで SP に変更を加えることができる (実際に行っている) ため、効果的なサポートを提供することは非常に困難です。
Linq は、.net の多くのタスクを非常に簡単かつ効率的に (開発時間的に) 実現する非常に優れたテクノロジです。また、Linq to SQL は、ストアド プロシージャを呼び出すための非常に優れたメカニズムを提供します。
現在、知識/学習曲線の不足 (時間の不足) が問題です。
SQL を使用して (ストアド プロシージャを介して) データベースに直接クエリを実行し、LINQ を使用してグループ化など、データに追加処理を行うことをお勧めします。
私は SQL が嫌いで、ここ 1 年ほど LINQ を使用しています。いつでも、SQL 構文よりも LINQ 構文を好みます。
もちろん、ストアドプロシージャまたはLinqの使用はあなたの選択ですが、どちらにも長所と短所があります。
基本的にLinqの長所として、データレイヤーを作成するために時間を費やす必要はありませんが、ストアドプロシージャでは、エンティティごとに新しいストアドプロシージャを作成する必要があります(おそらく、その「ストアドプロシージャ地獄」に対する一般的な解決策があるかもしれません)しかし、それを維持するのは複雑だと思います）。また、ストアド プロシージャのメンテナンスは、Linq よりも複雑だと思います (もちろん、Linq で少し時間を過ごした後です)。
しかし、予想どおり、ストアド プロシージャを使用してデータを取得する方が、Linq を使用するよりも高速です。
そして、Oracle およびその他のデータベースの Linq へのサポートが発生した後。まだストアド プロシージャを使用していて、データベースを変更する必要がある場合、または別のデータベースをサポートしたい場合は、これらのストアド プロシージャの Oracle および他のデータベース バージョンを作成する必要があります。