DAOパターンは.NETで広く使用されていますか？
DAO（データアクセスオブジェクト）は、.NETで一般的に使用されるパターンですか？私は常に、データレイヤーへのアクセスを提供する方法としてDAOを使用してきました。たとえば、EntityFramework ObjectContext上に薄いインターフェイスがあり、すべてのObjectSetをIObjectSetとして公開している場合があります。
複雑なクエリはDAOによって公開され、DAOはそれぞれこのインターフェイスに依存します。 GetProductsOnSale()やGetInfrequenlySoldProducts()のようなメソッドを公開するProductDAOがあるかもしれません。次に、私のコントローラーまたはプレゼンターはこれらのメソッドを使用します。これは、単体テストの特定の結果をスタブできるようにするために仮想的である可能性があります。
では、これは.NETで一般的に使用されているイディオムですか？何らかの理由で、このパターンを使用してオンラインで見た例の圧倒的多数はJavaに基づいています。 DAOのベストプラクティスの この質問 でさえ、C＃ではなくJavaとしてタグ付けされています。
他のコミュニティの何かを使用することに何の問題もありません。周りの人が違ったやり方をしているのではないかと少し恐れています...
これは、.NETの一般的なイディオムです。私はそれを使用し、多くの場所で使用されているのを見てきました。
フレームワークに組み込まれています System.Data 名前空間-クラスの多くは特殊なプロバイダー（SQL Server、Oracle、MySQLなど）の基本クラスであり、操作は基本クラスで実行されます。
ただし、あなたが説明していることは、単に データアクセスオブジェクト を使用するのではなく、 リポジトリパターン のように聞こえます。
これは多くのプロジェクトでも使用されていますが、フレームワークには組み込まれていません。
DAOパターンを多用しています。
あなたはEntityFrameworkについて言及しました。それに加えて、DAOはDataSetsやDataTablesよりもはるかに優れていると思います。これらはデータベースに非常に似ているため、私の好みのオブジェクトには十分ではありません。たとえば、DataRowsを複数のデータテーブルに追加することはできないため、ロードされたデータのサブセットを、それらを含むように構築されていないコンテナに移動せずに、異なるオブジェクトに渡すことはできません。 （つまり、DataRowはDataTableに含まれている必要があるように見えますが、一度に1つのDataTableにしか含めることができません。）DataRowViewsは扱いにくく、エンティティオブジェクトを別のリストに追加するほど直感的ではありません。
データアクセスをカプセル化するためのリポジトリパターンの使用に関する私の最大の推奨事項（これは確かに非常に優れたパターンです）は、汎用リポジトリを作成できるようにすることです。ただし、基本的にすべての標準CRUD操作にすぐにアクセスできる非常にスマートな汎用リポジトリを作成し、ISomeServiceファサードを超えて公開しない複雑なクエリ構造にアクセスできるようにします。
ジェネリックリポジトリを使用する上で最も重要なことは、継承に基づくのではなく、コンストラクタインジェクションに基づくリポジトリにすることです。このようにして、意味のあるビジネスドメインの境界を満たすために必要な多くの汎用リポジトリに依存するようにSomeServiceを構成できます。
私はこの概念について詳細なブログを書きました。 一般的な汎用で拡張可能なNHiberateリポジトリバージョン2の作成 。このブログ投稿はNHibernateを参照して具体的ですが、同じコアコンセプトを採用して、ほぼすべてのDAOに適用できます。
いくつか例を挙げると、Entity Framework、Linq2Sql、RavenDBなどの一部のツールでは、非常に洗練されたリポジトリ自体が公開されており、ラッパーを追加しても必ずしもメリットが得られない場合があります。