LINQとデータアクセスレイヤー

私は常に、自分のビジネスロジックとUIコードとは完全に別の「レイヤー」でデータアクセスコードを処理することを学びました。これは常に私にとって非常に優れたアーキテクチャであり、私が目にするすべての「ルール」またはベストプラクティスは、このスタイルのコーディング、特に単一責任の原則にうまく適合しています。

ほとんどのホームプロジェクトでは、私が作成した独自のORMを使用します。これは、常にオープンソースを作成することを目的としていました。しかし、それ以来、LINQが利用可能になりました。これは、私のORMが機能する方法と非常によく似ていました（しかし、より優れています）。

以前に自分のORMを使用して、今はLINQを使用して実行できないことはありません（REST統合のビットを除く）。だから私の質問です。LINQは新しいデータアクセスレイヤーですか？このレイヤーはもう必要ですか？私のBLLはLINQと直接通信する必要がありますか？それとも、この悪い習慣はまだですか？

編集：

元の質問はLINQ to Entitiesに関するものでしたが、LINQ to SQLに関しては興味深い答えがたくさんあります。両方の人々の考えは何ですか？LINQ to SQLでDALを実際に置き換えることはできませんが、Entity Frameworkは収集できますか？

LINQクエリをBLLに配置するだけで、コードが重複する可能性があります。それでも、LINQクエリのラッパーとなるリポジトリを作成します。これにより、データベースコードがBLLコードから分離され、データアクセスコードを変更する（つまり、Dapperに移動する、またはプリコンパイルされたクエリに移動する）場合に役立ちます。

リポジトリは簡単にモックできるので、単体テストにも役立ちます。

DALを使用することもできます。以前使用していたものではなく、LINQ to SQLを使用できます。それがとにかくそれをする方法です。BLLがLINQ to SQLを直接使用してデータにアクセスしないようにしてください。

Linqはデータアクセスに関するものではなく、任意のに対してlinqを使用できますIEnumerable。

最初はデータベースについて考えずにアプリケーションを設計しようとしましたか？つまり、アプリケーションを実装して、ある種のリポジトリを使用します。次に、任意の手法を使用してこれらのリポジトリを実装します。これにより、完全に分離されたソリューションが得られ、必要なデータアクセス層をプラグインできます。

そのデータアクセスレイヤーでは、独自のORMを使用することも、Linq to sqlを使用することもできます。データアクセスレイヤーが、定義したリポジトリを実装している限り、問題はありません。

「ビジネスロジックレイヤー」でトランザクションとクエリのパフォーマンスに対処したくない場合を除いて、DALは依然として必要です。

LINQは、クエリ宣言をデザイン時（別名、コンパイラチェック）のプロセスにします。

LINQクエリプロバイダー（LinqToSqlやLinqToEntitiesなど）は、これらの宣言されたクエリを実行時にSQLテキストに変換します。その後、DBMSは実行時クエリの解釈、実行時クエリプランの生成などを行います。

これらはDALのほんの一部です。