Linq to Entitiesを使用する場合は、別のデータレイヤーが必要ですか？

Question

Linq to Entitiesを使用する場合、個別のデータレイヤーを使用してデータベースアクセスを抽象化する必要がありますか、コードビハインドから直接Linqクエリを作成することは許容されます（または推奨することもできます）（Get、Add、Update、削除機能は既にEntity Frameworkに組み込まれています）。

Answer 1

私たちはLinq to EFを使用していますが、まだ別のデータレイヤーがあります。

今後、EFを使用したくない場合や、EFがサポートしていないデータベースをサポートする必要がある場合に、今後起こることがあります。抽象化のポイントの一部は、他のレイヤーに影響を与えずにすべてのレイヤーを変更できることです。

私たちのデータレイヤーは、単純なデータオブジェクトのロードと保存よりも少し複雑です。オブジェクトはEFからロードされた後、EFデータ・コンテキストから完全に切断され、ビジネス・オブジェクトに変換されます。 EFによって生成されたデータオブジェクトは、データレイヤーの上に露出されることはありません。 （これは、EFの接続されていないクライアント/サーバーアプリケーションのサポートが不十分なために行われるため、その部分を自分で管理する必要があります）

Answer 2

私の意見では、EntityフレームワークはDALです。一部のアプリケーションではまだ特定のテクノロジなのでラップしていますが、アプリケーション全体から抽象的な特定のテクノロジを試しています。したがって、別のビジネスオブジェクトに移動する必要がある場合、またはビジネスオブジェクトの作成方法を変更する必要がある場合は、アプリケーションの残りの部分に影響を与えずに行うことができます。

これは本当にすべてのOR/Mツールに適用されるので、あなたが得た応答のいくつかは興味深いでしょう。

Answer 3

デッドラインがどれくらい近くにあるか、開発したいアプリケーションのサイズは多分、おそらくはもっと多くのアプリケーションに依存します。

私はそう、データレイヤーを実装すると思います。たとえば、アプリケーションがOracleデータベースを使用して実行する必要がある場合（将来はいつか）、物事は非常に醜いものになるでしょう。

Answer 4

Linq-to-Entitiesは実装の詳細です。データレイヤーは、データとのやりとりから実装を抽象化することを意図しています。これにより、Linq-to-entitiesが適切ではなく、実装を変更する必要があることがわかった場合、システムの堅牢性が保証されます。したがって、はい、あなたはまだデータ層が必要です。