データマッパー、テーブルデータゲートウェイ（ゲートウェイ）、データアクセスオブジェクト（DAO）、およびリポジトリパターンの違いは何ですか？
https://stackoverflow.com/questions/804751
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
デザインパターンのスキルを磨こうとしていますが、これらのパターンの違いは何ですか？それらはすべて同じもののように見えます。特定のエンティティのデータベースロジックをカプセル化して、呼び出し元のコードが基礎となる永続化レイヤーの情報を持たないようにします。私の簡単な調査から、それらのすべては通常、標準のCRUDメソッドを実装し、データベース固有の詳細を抽象化します。
命名規則（CustomerMapper対CustomerDAO対CustomerGateway対CustomerRepositoryなど）以外に、違いはありますか？違いがある場合、いつどちらを選択しますか？
過去には、次のようなコードを記述していました（単純化された、当然-私は通常パブリックプロパティを使用しませんでした）：
public class Customer
{
public long ID;
public string FirstName;
public string LastName;
public string CompanyName;
}
public interface ICustomerGateway
{
IList<Customer> GetAll();
Customer GetCustomerByID(long id);
bool AddNewCustomer(Customer customer);
bool UpdateCustomer(Customer customer);
bool DeleteCustomer(long id);
}
すべてのメソッドに特定のデータベースロジックを実装する CustomerGateway クラスがあります。インターフェースを使用せず、CustomerGatewayのすべてのメソッドを静的にすることもあるので（テストが難しくなります）、次のように呼び出すことができます：
Customer cust = CustomerGateway.GetCustomerByID(42);
これは、Data MapperおよびRepositoryのパターンと同じ原則のようです。 DAOパターン（これはGatewayと同じものですか？）もデータベース固有のゲートウェイを推奨しているようです。
何か不足していますか？同じことを3〜4種類の方法で行うのは少し奇妙に思えます。
解決
用語の例; DataMapper、DAO、DataTableGateway、Repositoryはすべて同じ目的を持っています（使用する場合、Customerオブジェクトを取得する予定です）が、意図/意味と結果の実装が異なります。
リポジトリ ＆quot;より精巧なクエリ機能を除いて、コレクションのように機能します [ Evans、Domain Driven Design ]であり、＆quot;メモリファサード内のオブジェクト＆quot; （リポジトリのディスカッション）
A DataMapper ＆quot;オブジェクトとデータベース間でデータを移動し、相互に依存せず、マッパー自体とは無関係に保ちます＆quot; （ファウラー、PoEAA、マッパー）
TableDataGateway は、データベーステーブルへの＆quot;ゲートウェイ（外部システムまたはリソースへのアクセスをカプセル化するオブジェクト）です。 1つのインスタンスがテーブル内のすべての行を処理します＆quot; （ファウラー、PoEAA、TableDataGateway ）
DAO ＆quot;データリソースのクライアントインターフェースをデータアクセスメカニズムから分離する/特定のデータリソースのアクセスAPIを汎用クライアントインターフェースに適合させる＆quot; ＆quot;データを使用するコードとは無関係に変更するデータアクセスメカニズム＆quot; （サンブループリント）
リポジトリは非常に汎用的であり、データベースの相互作用の概念を公開していません。 DAOは、さまざまな基礎となるデータベース実装を使用できるようにするインターフェイスを提供します。 TableDataGatewayは、具体的には単一のテーブルの薄いラッパーです。 DataMapperは、Modelオブジェクトがデータベースの表現とは独立して（時間とともに）進化できるようにする仲介役として機能します。
他のヒント
ソフトウェアデザインの世界では（少なくとも、そうだと思う）、よく知られている古いものやパターンの新しい名前を発明する傾向があります。そして、新しいパラダイム（おそらく既存のものとは少し異なるかもしれません）がある場合、通常、各層に新しい名前のセット全体が付属します。したがって、「ビジネスロジック」 「サービス層」になります; SOAを行うと言って、DAOはDDDを行うと言ってリポジトリになります（そして、それぞれが実際にはまったく新しくてユニークなものではありませんが、同じ本に集められた既知の概念の新しい名前です） 。ですから、これらの現代のパラダイムや頭字語がまったく同じことを意味すると言っているわけではありませんが、あなたは本当にそれについて過度に偏執的であってはなりません。ほとんどがこれらは同じパターンであり、異なるファミリーからのものです。
データマッパーとテーブルデータゲートウェイ 長い話を短くします：
最終的には、両方ともインメモリオブジェクトとデータベース間のメディエーターとして機能します。
良い点があります。最もよく知っているものを選んでください。私は明確にするのに役立つかもしれないいくつかのことを指摘したいです。
Table Data Gatewayは、主に単一のテーブルまたはビューに使用されます。すべての選択、挿入、更新、および削除が含まれます。したがって、顧客はあなたの場合のテーブルまたはビューです。したがって、テーブルデータゲートウェイオブジェクトの1つのインスタンスがテーブル内のすべての行を処理します。通常、これはデータベーステーブルごとに1つのオブジェクトに関連しています。
Data Mapperはドメインロジックからより独立しており、結合度は低くなっています（ただし、結合があるか結合していないと思います）。オブジェクトとデータベース間でデータを転送し、それらを相互に依存せず、マッパー自体から独立させるのは、単なる中間層です。
したがって、通常、マッパーには挿入、更新、削除などのメソッドがあり、テーブルデータゲートウェイにはgetcustomerbyId、getcustomerbyNameなどがあります
データ転送オブジェクトは、主に上記の2つのパターンのようなデータソースパターンではなく、分布パターンであるため、上記の2つのパターンとは異なります。主にリモートインターフェイスを使用していて、各通話が高価になる可能性があるため、通話のチャットを少なくする必要がある場合に使用します。そのため、通常、有線でシリアル化できるDTOを設計します。これにより、すべてのデータをサーバーに戻し、さらにビジネスルールや処理を適用できます。
今まで使用する機会がなかったので、他の回答を見ているので、リポジトリパターンに精通していません。
以下は私の理解です。
TableGateWay / RowDataGateWay ： このコンテキストでは、ゲートウェイは各「ドメインオブジェクト」を持つ特定の実装を参照しています。各「ドメインオブジェクトゲートウェイ」へのマッピング。たとえば、 Person がある場合、ドメインオブジェクトPersonをデータベースに保存する PersonGateway があります。 Person、Employee、Customerなどがある場合、PersonGateway、EmployeeGateway、およびCustomerGatewayがあります。各ゲートウェイには、そのオブジェクトに固有のCRUD機能があり、他のゲートウェイとは関係ありません。ここには再利用可能なコード/モジュールはありません。ゲートウェイは、「id」を渡すかどうかに応じて、RowDataGatewayまたはTableGatewayにさらに分割できます。または「オブジェクト」。通常、ゲートウェイはアクティブレコードと比較されます。ドメインモデルをデータベーススキーマに結び付けます。
リポジトリ/ DataMapper / DAO ：それらは同じものです。これらはすべて、データベースエンティティをドメインモデルに転送する永続層を参照します。ゲートウェイとは異なり、Repository / DataMapper / DAOは実装を隠します。 Personの背後にPersonGatewayがあるかどうかはわかりません。あなたは気にしないかもしれませんし、そうでないかもしれません。知っているのは、各ドメインオブジェクトに対してCRUD操作がサポートされている必要があるということだけです。データソースとドメインモデルを分離します。
