DAOとリポジトリのパターンの違いは何ですか？

データアクセスオブジェクト（DAO）とリポジトリパターンの違いは何ですか？Enterprise Java Beans（EJB3）、インフラストラクチャーとしてHibernate ORM、設計手法としてドメイン駆動設計（DDD）とテスト駆動開発（TDD）を使用してアプリケーションを開発しています。

DAOデータの永続性を抽象化したものです。オブジェクトのコレクションの
Repository抽象化です。

DAO多くの場合、テーブル中心のデータベースに近いと見なされます。
Repositoryドメインに近いと見なされ、集合ルートでのみ処理されます。

Repositoryを使用して実装できますDAOが、反対のことはできません。

また、a 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は、データを検索するクラスです（ほとんどの場合はファインダーですが、一般的にはデータの格納にも使用されます）。パターンは同じタイプのデータを格納することを制限しないため、関連オブジェクトを検索/格納するDAOを簡単に作成できます。

たとえば、次のようなメソッドを公開するUserDaoを簡単に作成できます。

Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)

これらはすべてユーザー（およびセキュリティ）に関連しており、同じDAOで指定できます。これは、リポジトリには当てはまりません。

最終的に

両方のパターンは実際には同じことを意味します（データを格納し、データへのアクセスを抽象化し、両方ともドメインモデルに近く表現され、DB参照をほとんど含みません）。ただし、DAOの使用方法は少し異なる場合があります。もう少し柔軟で汎用的ですが、リポジトリはもう少し具体的でタイプのみに制限されます。

DAOとリポジトリパターンは、データアクセス層（DAL）を実装する方法です。それでは、まずDALから始めましょう。

データベースにアクセスするオブジェクト指向アプリケーションには、データベースアクセスを処理するためのロジックが必要です。コードをクリーンでモジュール化しておくために、データベースアクセスロジックを別のモジュールに分離することをお勧めします。階層化アーキテクチャでは、このモジュールはDALです。

これまでのところ、特定の実装については触れていません。データベースアクセスロジックを別のモジュールに配置するという一般的な原則のみです。

では、この原則をどのように実装できますか？特に、Hibernateのようなフレームワークでこれを実装する既知の方法の1つは、DAOパターンです。

DAOパターンはDALを生成する方法であり、通常、各ドメインエンティティには独自のDAOがあります。たとえば、Userand UserDao、Appointmentand 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が上記の操作をサポートするインターフェースで設計されている場合、DAOはリポジトリパターンのインスタンスです。考えてみてください。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は、データベース/データファイルまたはその他の永続化メカニズムの抽象化を提供するため、永続化レイヤーは、その実装の詳細を知らなくても操作できます。

一方、Repositoryクラスでは、単一のRepositoryメソッド内で複数のDAOクラスを使用して、「アプリの観点」から操作を実行できます。したがって、ドメイン層で複数のDAOを使用する代わりに、リポジトリを使用してそれを実行します。リポジトリは、次のようないくつかのアプリケーションロジックを含む可能性のあるレイヤーです。データがメモリ内キャッシュで利用できる場合は、キャッシュからフェッチし、そうでない場合は、ネットワークからデータをフェッチして、次回の取得のためにメモリ内キャッシュに格納します。

リポジトリは、適切に設計されたDAOにすぎません。

ORMはテーブル中心ですが、DAOではありません。

車がどこにどのように永続化されていても、DAO自体がORMリポジトリ/エンティティまたは任意のDALプロバイダーとまったく同じように実行できるため、リポジトリで複数のDAOを使用する必要はありません。1テーブル、2テーブル、nテーブル、テーブルの半分、 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

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

非常に単純な文で：大きな違いは、リポジトリがコレクションを表すのに対し、DAOはデータベースに近く、多くの場合、テーブル中心になっています。

春のフレームワークには、リポジトリと呼ばれる注釈があり、この注釈の説明には、リポジトリに関する有用な情報が含まれています。これは、この議論に役立つと思います。

注釈付きのクラスが「リポジトリ」であることを示します。これは、もともとドメイン駆動設計（Evans、2003）によって「オブジェクトのコレクションをエミュレートするストレージ、検索、および検索動作をカプセル化するメカニズム」として定義されています。

「データアクセスオブジェクト」などの従来のJava EEパターンを実装するチームも、このステレオタイプをDAOクラスに適用できます。ただし、データアクセスオブジェクトとDDDスタイルのリポジトリの違いを理解してから行う必要があります。この注釈は汎用のステレオタイプであり、個々のチームはセマンティクスを絞り込み、必要に応じて使用できます。

このようにアノテーションが付けられたクラスは、PersistenceExceptionTranslationPostProcessorと組み合わせて使用​​した場合、Spring DataAccessException変換の対象になります。注釈付きクラスは、ツールやアスペクトなどの目的で、アプリケーションアーキテクチャ全体におけるその役割についても明確化されています。