DAOとリポジトリのパターンの違いは何ですか？
データアクセスオブジェクト（DAO）とリポジトリのパターンの違いは何ですか？エンタープライズJava Beans（EJB3）、インフラストラクチャとしてHibernate ORM、設計手法としてドメイン駆動設計（DDD）とテスト駆動開発（TDD）を使用してアプリケーションを開発しています。
DAOは、データの永続化を抽象化したものです。Repositoryは、オブジェクトの集まりを抽象化したものです。
DAOはデータベースに近いと考えられ、多くの場合テーブル中心です。Repositoryは、ドメインに近いと見なされ、集約ルートのみを扱います。
RepositoryはDAOを使って実装できますが、その逆はできません。
また、Repositoryは一般により狭いインターフェースです。それは単にGet(id)、Find(ISpecification)、Add(Entity)を持つオブジェクトの集まりであるべきです。
UpdateのようなメソッドはDAOには適していますがRepositoryには適していません - Repositoryを使用する場合、エンティティへの変更は通常別のUnitOfWorkによって追跡されます。
実装がRepositoryと呼ばれる実装を見るのは一般的に思えますが、それは実際にはDAOに近いので、両者の違いについて混乱があると思います。
わかりました、私がコメントに入れたものをよりよく説明できると思います:)。そのため、DAOはリポジトリよりも柔軟性の高いパターンですが、基本的には、どちらも同じように見えます。両方を使用したい場合は、DAOのリポジトリを使用します。以下にそれぞれ説明します。
寄託：
それは特定の種類のオブジェクトのリポジトリです - それはあなたがそれらを格納するだけでなく特定の種類のオブジェクトを検索することを可能にします。通常は1種類のオブジェクトのみを処理します。例えば。 AppleRepositoryを使用すると、AppleRepository.findAll(criteria)またはAppleRepository.save(juicyApple)を実行できます。リポジトリではドメインモデルの用語を使用していることに注意してください（DBの用語ではありません。データの保存方法には関係ありません）。
ほとんどの場合、リポジトリはすべてのデータを同じテーブルに格納しますが、パターンはそれを必要としません。ただし、1種類のデータしか処理されないため、1つのメインテーブルに論理的に接続されます（DBの永続化に使用されている場合）。
DAO - データアクセスオブジェクト（つまり、データにアクセスするためのオブジェクト）
DAOはあなたのためにデータを見つけるクラスです（それはほとんどFinderですが、それはデータを格納するのにもよく使われます）。このパターンでは、同じ種類のデータを保存することが制限されていないため、関連オブジェクトを検索/保存するDAOを簡単に使用できます。
例えば。あなたは簡単にのようなメソッドを公開するUserDaoを持つことができます
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
これらはすべてユーザー（およびセキュリティ）に関連しており、同じDAOの下で指定できます。これはリポジトリには当てはまりません。
最後に
両方のパターンは実際に同じことを意味します（データを格納し、それへのアクセスを抽象化し、どちらもドメインモデルの近くで表現され、DB参照をほとんど含まない）。もう少し柔軟/汎用的ですが、Repositoryはもう少し具体的でタイプに限定されています。
DAOとリポジトリパターンは、データアクセス層（DAL）を実装する方法です。それでは、最初にDALから始めましょう。
データベースにアクセスするオブジェクト指向アプリケーションには、データベースアクセスを処理するための何らかのロジックが必要です。コードをクリーンでモジュラーに保つために、データベースアクセスロジックを別のモジュールに分離することをお勧めします。階層化アーキテクチャでは、このモジュールはDALです。
これまでのところ、特定の実装については話していません。データベースアクセスロジックを別のモジュールに入れるという一般原則のみです。
さて、どうやってこの原則を実行することができますか？さて、特にHibernateのようなフレームワークでこれを実装する1つの既知の方法はDAOパターンです。
DAOパターンはDALを生成する方法です。通常、各ドメインエンティティは独自のDAOを持ちます。たとえば、UserとUserDao、AppointmentとAppointmentDaoなどです。Hibernateを使ったDAOの例： http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .
それではリポジトリのパターンは何ですか？ DAOと同様に、リポジトリパターンもDALを実現する方法です。リポジトリパターンの主な点は、クライアント/ユーザーの観点からは、コレクションとして見えるか、動作する必要があるということです。コレクションのように振る舞うことが意味するのは、それがCollection collection = new SomeCollection()のようにインスタンス化されなければならないということではありません。代わりに、追加、削除、含むなどの操作をサポートする必要があります。これがリポジトリパターンの本質です。
実際には、たとえばHibernateを使用する場合、リポジトリパターンはDAOで実現されます。つまり、DALのインスタンスは、DAOパターンとリポジトリパターンの両方のインスタンスになることができます。
リポジトリパターンは必ずしもDAOの上に構築されるものではありません（一部の人が示唆するように）。 DAOが上記の操作をサポートするインターフェースを使用して設計されている場合、それはRepositoryパターンのインスタンスです。考えてみてください。DAOがすでにコレクション風の一連の操作を提供している場合、その上に追加のレイヤーが必要になることは何ですか？
率直に言って、これは技術的な区別ではなく意味的な区別のように見えます。データアクセスオブジェクトというフレーズは、「データベース」をまったく参照していません。そして、あなたはそれをデータベース中心になるように設計することができますが、私はほとんどの人がそうすることを設計上の欠陥と考えるだろうと思います。
DAOの目的は、データアクセスメカニズムの実装の詳細を隠すことです。リポジトリのパターンはどう違いますか？私が言うことができる限りでは、そうではありません。 DAOとは違うと言うのは、オブジェクトのコレクションを扱う/返すことは正しいことではないからです。 DAOはオブジェクトのコレクションを返すこともできます。
私がリポジトリパターンについて読んだことはすべてこの区別に頼っているようです：悪いDAOデザインと良いDAOデザイン（別名リポジトリデザインパターン）。
リポジトリは、ドメイン駆動設計の一部であり、ドメイン設計および共通言語の一部である、より抽象的なドメイン指向の用語です。DAOは、データアクセステクノロジの技術的抽象概念です。データ。
これらのリンクを確認してください。
http://warren.mayocchi.com/2006/07/27/repository-or-dao/http ：//fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
主な違いは、DAOがエンティティへのアクセスを処理するのに対して、リポジトリは集約内の集約ルートへのアクセスを処理することです。したがって、リポジトリが集約ルートの実際の永続性をDAOに委任するのが一般的です。さらに、集約ルートは他のエンティティのアクセスを処理する必要があるため、このアクセスを他のDAOに委任する必要があります。
リポジトリは、うまく設計されたDAOに他なりません。
ORMはテーブル中心ですがDAOではありません。
1台、2台、n台、半分の台、1台の台、2台の台、1台の台、2台の台、1台の台、2台の台、 Webサービス、テーブル、Webサービスなど。サービスはいくつかのDAO /リポジトリを使用します。
私自身のDAO、たとえばCarDaoはCar DTOのみを扱い、つまり、入力にはCar DTOのみを取り、出力にはcar DTOまたはcar DTOコレクションのみを返します。
リポジトリと同様に、DAOは実際にはビジネスロジックのためのIoCであり、永続インタフェースが永続戦略や遺産によって脅かされないようにします。 DAOは永続化戦略をカプセル化し、ドメイン関連の永続インターフェースを提供します。リポジトリは、明確に定義されたDAOが実際には何であるかを理解していなかった人にとっては単なる別の言葉です。
DAOまたはリポジトリパターンが以下の状況に最も適しているかどうかを調べてみてください。永続的なメカニズムのためのRDBMS、LDAP、OODB、XMLリポジトリなどのさまざまな種類のデータソースに対する統一データアクセスAPIを提供したいとします。フラットファイル.
興味があれば、以下のリンクも参照してください。
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
DAOは、データベース/データファイルまたはその他の永続化メカニズムを抽象化して、永続化層を実装の詳細を知らなくても操作できるようにします。
リポジトリクラスでは、単一のリポジトリメソッドで複数のDAOクラスを使用して、アプリケーションの観点から操作を実行できます。そのため、ドメイン層で複数のDAOを使用する代わりに、リポジトリを使用して実行します。リポジトリは次のようなアプリケーションロジックを含むことができる層です：データがインメモリキャッシュで利用可能ならそれ以外の場合はキャッシュからそれを取得し、ネットワークからデータを取得します次回の検索のためにメモリ内キャッシュに保存します。
非常に簡単な文で：リポジトリがコレクションを表すのに対して、DAOはデータベースにより近く、テーブル中心であることが多いという大きな違いがあります。