リポジトリパターンとDALオブジェクトの作成

私が学んだ限り、にはIRepositoryが含まれている必要がありますCRUD。その後、我々はこれを継承するIRepositoryような当社の他のインターフェイスにIProductして実装するIProduct具象クラスをProductRepository、などの方法でGetAllProducts()、Top5Products()。

n層アーキテクチャでも同じことができます。作成、のようにDAL Class Library、そこにクラスを定義するProductような方法でGetAllProducts()、Top5Products()。

両方において、DAL.ProductそしてRepo.ProductRepository、我々は初期化したクラスDB ContextでEntity Framework、当社の関連データを照会します。

呼び出しは両方Repo.ProductRepositoryまたはDAL.Productメソッドから似ていますBLL

これらの類似点を考慮して、私の質問はレポの利点は何ですか？私はn層アーキテクチャを使用して非常に簡単に同じことを行うことができます（Controller、BLL Class Library、DAL Class Library）。

私の理解は：

• DAL（データアクセス層）を指し層あなたの永続化技術とアプリケーションロジックの間に座っているあなたのソフトウェアインチ その目的は、データアクセスの問題をアプリケーションの残りの問題から分離することです。それは一般的な概念です。

• リポジトリはDDD（ドメイン駆動設計）のコンセプトです。

DDDでは、リポジトリは、特定のAggregateのすべてのデータアクセスの問題をカプセル化する責任があります。これには、Aggregateの読み取りおよび書き込み中に一貫性を確保する責任が伴います。そして、集計は、関連するエンティティ（例えば、のグループであるProduct、Storeなど）。

したがって、リポジトリは、そのアグリゲートの永続性と一貫性の問題を特に認識しています。あなたの一般的な DALは、最も可能性が高いで構成され、特定のリポジトリ

TL; DR;

• DALは、データアクセスの問題を抽象化するための一般的な用語です。
• リポジトリは、DDDからの類似した、しかしより具体的な概念です。
• DALは複数のリポジトリで構成される可能性があります。

2つの異なる補完的な概念を比較しています。

• データアクセス層は、データへのアクセス抽象化する予定の建築層です。アクセスをどのように抽象化するかについては触れていません。
• リポジトリは、 DAL（の終了時にパターンのリストを見るに属する特定のパターンであり、このリンク）。これは、データへの特定のアクセスを抽象化する方法を正確に示しています。データストアへのインターフェイスのようなコレクションを提供することによって。

あなたの例のDAL

興味深いことに、クラスライブラリの例ではDAL.Product、リポジトリのようです。したがって、実際には違いが見られないのは正常です。実装の観点からは、同じです（この特定の場合）。
しかし、そうである必要はありません。DALは別の方法で実装できます。次に例を示します。

• データベース抽象化レイヤーに依存するアクティブレコード。
• 行データゲートウェイから取得した貧血ドメインオブジェクト（注意、アンチパターン！）
• または、なぜそうでないのか、各クエリがオブジェクトを取得する特定の方法を実装する、異なるクエリオブジェクトから取得されたドメインオブジェクト
• リポジトリ
• それらすべてのミックス

リポジトリの違い

リポジトリの概念は、アーキテクチャモデルと実装には依存しません。レイヤーやデータベースを考える必要はありません。ドメインを設計するときに知っておく必要があるのは、オブジェクトが、永続性を提供する特別な種類のコレクションであるリポジトリにあるということだけです。これにより、ドメイン設計に非常に適しており、ドメイン駆動設計の重要な要素である理由が説明されています。

DDDでは、リポジトリにはいくつかのルールがあります。これらは、アグリゲート（独立したエンティティ、またはアグリゲートルートに依存する関連エンティティのグループ）へのアクセスを提供し、アグリゲートごとに1つのリポジトリがあります。