LINQ-LINQは通常どのレイヤーに分類されるべきですか、DAL？

Question

LINQをどのレイヤーに（そしてなぜ）含めるべきかについて、さまざまなアイデアや視点を収集したかっただけです

Answer 1

linqで何をしたいかによって異なります。 linq2sqlを使用するときは、DALをお勧めしますが、Linqは単なるデータベースアクセスではありません。リスト、つまりビジネスオブジェクトの無数のオブジェクトなどを操作するために使用できます... Linq自体は、アプリケーションのあらゆる場所で役立ちます。

Answer 2

LINQ =言語統合クエリ。これは、データベースからリスト/コレクション、XMLへのすべてを照会できる照会拡張機能です。クエリ言語はどのレイヤーでも役立ちます。

ただし、多くの人がLINQ to SQLを単なる「LINQ」と呼んでいます。そのコンテキストでは、L2Sを使用している場合は、BLL / DALの組み合わせが意味を持ち、データベースに対してLINQクエリを実行します。もちろん、上位層の新しい（Linq to objects）クエリの同じクエリの結果に対して後続のクエリを実行することを除外しません...

Answer 3

DataContextから派生したオブジェクトをDALレイヤー自体と見なしますが、LINQは非常に柔軟なインターフェイスです。そのため、ビジネスレイヤーで直接LINQクエリを使用します。

Answer 4

両方。 DataContextはDALであり、デザイナーを使用する場合、SQLオブジェクト（テーブル、ビュー）にマップされる自動生成された部分クラスは、ビジネスレイヤーの一部と見なすことができます。必要に応じて検証とセキュリティを強化するために、いくつかの部分メソッドを実装する部分クラスを実装します。一部のビジネスルールはDBオブジェクトに直接マップせず、他のクラスを介して処理されます。

Answer 5

Linq to Sqlを実行している場合は、DALで常に実行する必要があると思います。ただし、単にフィルタリングしているオブジェクトに対してLinqを実行している場合は、別のオブジェクトで遊ぶことができます。これはBLレイヤーです。

Answer 6

LINQは非常に低いレベル（DAL）である必要があり、BLLにラップする必要があると思います。

LINQ to SQLが生成するモデルの部分的なアクセシビリティを使用することを好む多くの人々を知っていますが、利益の明確な分離があるべきだと思います（私がそこで何をしたかを参照してください）。ビジネスロジックを使用する場合は、データアクセスロジックから完全に分離する必要があると思います。

それが難しいのは、コード内でSystem.Linq行を使用している場所であればどこでも、これらのLINQ拡張メソッドをチェーンし続けることができるという事実だと思います。繰り返しになりますが、LINQは定義に属し、可能な限り低いレベルにあるべきだと思います。また、LINQの使用をBLLでラップすると、TDD /ユニットテストが大幅に簡単になります。

Answer 7

従来の「データアクセスレイヤー」または「データアクセスオブジェクト」でlinqを使用します。これにより、コードのモジュール化が可能になり、データコードを1か所で促進し（同じコードをいくつかの異なる場所でカットアンドペーストする）、異なるフロントエンドを比較的簡単に開発できます。

Answer 8

それはアプリケーションのアーキテクチャに依存し、プレゼンテーションモデルがデータモデルとどれだけ一致するかを大きく変えます。私は、LINQによって作成されたデータオブジェクトとアクセスメソッドからビジネスロジック操作を分離することに同意します。また、データコンテキストを内部クラスにできるように、すべてのデータレベルの操作をマネージャークラス内にラップする傾向があります。

Answer 9

Linqのポイントは、DALを置き換えることだと思います。

古いDALに相当するのは、DBMLファイルの背後にある自動生成されたコードと、Linqが追加できない余分なものです。