私は常に、Linq2SQL クエリをあらゆる場所に、ほぼすべてのクラスに挿入してきました。
Linq2SQL クエリをどこに配置するかについて、あなたの戦略を知りたいですか?
それらを別々のデータレイヤークラスに配置しますか、それともどこでも使用される場所に保存しますか?
Linq2SQL クエリの戦略を変更し、それらを別の DataLayer クラスに格納する必要があると思います。TDD を効率的に実行し、Dependency Injection と Solid の原則に準拠するには、必須だと思います。
すべての LinqToSQL 呼び出しを 1 つの DAL に完全にラップしました。私の Web サイトとビジネス レイヤーは、私が使用している永続化フレームワークを認識していません。このようにすれば、LinqToSql が実際に機能しなくなった場合や、まったく新しいフレームワークを使用することにした場合でも、DB 呼び出しを行ったすべての場所を探し出す必要はありません。
再利用にも役立ちます。同じデータベースを使用する他のプロジェクトで同じビジネスまたは DAL を使用できます。
LINQ は言語構造です。必要なのは、DAL がエンティティを IEnumerable または IQueryable として公開し、それに対して LINQ を使用できることだけです。DAL は、エンティティを適切に公開する限り、LINQ2SQL または LINQ2Entities または独自のカスタム コードに基づくことができます。LINQ2SQL を使用するとクエリの実行が遅延するなど、いくつかの利点がありますが、厳密には必要ではありません。DAL 以外での LINQ の使用を避ける意味はありません。DAL を LINQ2SQL ベース以外のものに置き換えたい場合は、それが可能です。LINQ ベースのコードが期待するインターフェイスを維持している限り、問題はありません。
編集:私にとっての結論は、DAL に到達するまで、LINQ2SQL クエリではなく、単なる LINQ であるということです。より優れたものに置き換えられない限り、LINQ が言語から消えることはありません。LINQ2SQL になっているのは、DAL が LINQ2SQL で実装されていることです。私のコードの残りの部分は、これがそうであることを知りません (または気にしません)。LINQ2Objects または LINQ2Entities または ...
すべてのLinq2SQLクエリを別のクラスに入れると、それにアクセスするビジネスオブジェクトをテストするときに、「モック/スタブ」に簡単に置き換えることができます。
それとも私は間違っていますか？
LINQクエリをLINQ2SQLクエリであると考えている場合は、要点が少し欠けています。
LINQクエリがあります。ビジネスレイヤーは、データレイヤー（データコンテキスト）でLINQクエリを実行することにより、データレイヤーにアクセスします。LINQ2SQLは、LINQクエリがSQLServerにアクセスできるようにするコンポーネントです。
これは深刻な単純化ですが、一般的なポイントは、すべてのLINQをビジネスレイヤーから隠すと、存在する理由から実際にはメリットが得られないということです。
LINQ2SQLでDBスキーマを好きな程度に抽象化できない場合は、代わりにEntityFrameworkの使用を検討する必要があります。
DAL DLL で Linq2SQL を使用しました。私は懸念の分離が好きで、他のサイトやアプリが同じデータベースにアクセスする必要がある場合は、DLL からかなりのコードを再利用できます。したがって、すべての Linq2SQL はこの DAL に格納されます。Linq 自体については、必要に応じてサービス レイヤーとプレゼンテーション レイヤーの両方で使用しています。
Linq2SQL DLL のレイアウト
SQL table.columns を Linq カタログ (SqlRepository) にマップするためのマッピング .dbml ファイルの作成
サービス層クラスに対応し、適切な Linq カタログ クラスを使用する SQL リポジトリ クラスを作成しました。
各 SQL リポジトリ クラスにインターフェイスを追加して、サービス レイヤーがインターフェイスと直接連携するようにしました
SQL リポジトリ クラスがサービス層とやり取りするビジネス モデルを作成しました。
それが LINQ2SQL のポイントであり、LINQ2SQL の優れた点の多くを再作成するという理由だけで、必ずしも個別のビジネス オブジェクトを作成する必要はありません。
ただし、L2SQL コードを含む静的クラスを含むクラス ライブラリを作成することをお勧めします。これにより、単一のアセンブリを置き換えてビジネス ロジックを変更できるという利点が得られます。さらに、データにアクセスするための追加のメソッドがある場合、静的クラスはそのロジックに適した場所です。
ただし、ニーズがもう少し複雑で、独自のマッピングを作成してもかまわない場合は、Florian に同意します。
データベースにアクセスする必要がある場合は、接続文字列 (データベース) とマッピング ファイル (マップするテーブル) を使用して、Helpers.DataContext をインスタンス化します。
これにより、懸念事項が適切に分離されます。
私の最新のプロジェクトでは、ASP.NET MVC フレームワークと LINQ-to-SQL を使用しています。そのため、データ層のリポジトリ パターンに大きく依存しています。これは私の最初の LINQ-to-SQL プロジェクトであるため、データベース スキーマは単一の DataContext クラス内で表されます。後のプロジェクトが登場したら、再利用のために共通の DataContext を分割できます。
特定のリポジトリに実装する予定のすべての署名を保持するインターフェイスを作成します。これは通常、単一の複雑なオブジェクトを表します。そのインターフェースに基づいて、2 つのクラスを実装します。1 つは本番用、もう 1 つはテスト用です。すべての LINQ-to-SQL クエリは、リポジトリ クラスに保持されています。コントローラー コードでは、データ アクセス メソッドのリポジトリにアクセスします。ビューにクエリを含めません。リポジトリ メソッドを使用してコントローラーに入力されるカスタム ビュー モデル クラスを使用します。
私は個人的に「ベース」クエリを作成し、IQueryable を公開します。
私のビジネス オブジェクトでは、具体的な結果を返すのが好きなので、通常は QueryByExpression スタイルのメソッドを内部専用にしてから、基準を渡すことができるメソッド スタブを作成し、クエリを処理するメソッドで、データベースを作成し、結果の IEnumerable を返します。コンテキストなどを必要とするアプリの残りの部分は公開しません。
しかし、上記の多くの人々が言ったように、私は同意する必要があります.IQueryableをコードに公開することは恐ろしいことではありません.Linq2Sqlのものにもう少し縛られるだけです.
メソッドを公開するが、IQueryable 型を公開しないビジネス オブジェクトを作成してもかまわない場合は、そのほうがよいと思いますが、ビジネス オブジェクトのセットアップと構成は面倒です。テストも簡単だと思いますが、それは私だけです。再利用性も考慮してください。バグを修正すると、2 年後にコード内の 30 の異なる場所に存在しなくなります。
ちょうど私の2セント。