データマッパー、テーブルデータゲートウェイ（ゲートウェイ）、データアクセスオブジェクト（DAO）、リポジトリパターンの違いは何ですか？

デザインパターンのスキルを磨こうとしていますが、これらのパターンの違いは何ですか？それらはすべて同じもののように見えます-特定のエンティティのデータベースロジックをカプセル化して、呼び出し元のコードが基になる永続性レイヤーを認識しないようにします。私の簡単な調査から、それらすべては通常、標準の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パターン（ゲートウェイと同じものだと思いますか？）もデータベース固有のゲートウェイを推奨しているようです。

何か不足していますか？同じことを正確に行うために3〜4つの異なる方法があるのは少し奇妙に思えます。

あなたの例の用語; DataMapper、DAO、DataTableGateway、Repositoryはすべて同じような目的があります（私が使用すると、Customerオブジェクトが返されることを期待しています）が、意図や意味が異なり、実装も異なります。

A リポジトリが 「より複雑なクエリ機能を除いて、コレクションのように作用する」 [ エバンス、ドメインデザインを駆動 ]とみなすことができる「メモリファサードのオブジェクト」（リポジトリ議論）

A DataMapperの 「互いのそれらの独立したマッパー自体を維持しながら移動するオブジェクトとデータベースの間でデータを」（ファウラー、PoEAA、マッパー）

A TableDataGatewayである「データベース・テーブルへのゲートウェイ（外部システムまたはリソースへのアクセスをカプセル化するオブジェクト）。つのインスタンスハンドルテーブル内のすべての行」（ファウラー、PoEAA、TableDataGateway）

DAOは 「/そのデータアクセスメカニズムからデータリソースのクライアント・インターフェースを分離し、一般的なクライアント・インタフェースに固有のデータリソースのアクセスAPIを適応させる」許可「のデータを使用するコードとは独立して変更するには、データアクセスメカニズムを」（日青写真）

リポジトリは非常に一般的であり、データベースの相互作用の概念を公開していません。DAOは、基盤となるさまざまなデータベース実装を使用できるようにするインターフェイスを提供します。TableDataGatewayは、具体的には単一のテーブルの薄いラッパーです。DataMapperは仲介として機能し、Modelオブジェクトがデータベース表現とは独立して（時間とともに）進化できるようにします。

ソフトウェア設計の世界（少なくとも、私はそう思う）では、よく知られている古いものやパターンに新しい名前を付ける傾向があります。また、新しいパラダイム（おそらく既存のものとわずかに異なる）がある場合、通常は各層に新しい名前のセット全体が付属しています。つまり、SOAを行うと言っただけで「ビジネスロジック」が「サービスレイヤー」になり、DDDを行ったという理由だけでDAOがリポジトリになります（これらのそれぞれは、実際にはまったく新しいものではなく、一意ではありませんが、新しい名前です。同じ本に集められた既知の概念の場合）。したがって、これらすべての現代的なパラダイムや頭字語がまったく同じことを意味しているとは言っていませんが、それについて過度に偏執的であってはなりません。ほとんどの場合、これらは同じパターンですが、異なる家族からのものです。

データマッパーvsテーブルデータゲートウェイ 長い話を簡単に言うと：

あなたは良い点を持っています。最もよく知っているものを選択してください。私は明確にするのに役立つかもしれないいくつかのことを指摘したいです。

テーブルデータゲートウェイは、主に単一のテーブルまたはビューに使用されます。すべての選択、挿入、更新、および削除が含まれます。したがって、お客様はあなたの場合、テーブルまたはビューです。したがって、テーブルデータゲートウェイオブジェクトの1つのインスタンスは、テーブル内のすべての行を処理します。通常、これはデータベーステーブルごとに1つのオブジェクトに関連しています。

Data Mapperはどのドメインロジックからも独立しており、結合性は低くなります（結合があるか結合していないかのどちらかだと思います）。オブジェクトとデータベース間でデータを転送し、それらを相互に独立させ、マッパー自体を維持するのは、単なる中間層です。

そのため、通常はマッパーに挿入、更新、削除などのメソッドがあり、テーブルデータゲートウェイにはgetcustomerbyId、getcustomerbyNameなどがあります。

データ転送オブジェクトは、主に分散パターンであり、上記の2つのパターンのようなデータソースパターンではないため、上記の2つのパターンとは異なります。主にリモートインターフェイスを使用していて、通話ごとに費用がかかる可能性があるため、通話の雑談を減らす必要がある場合に主に使用します。したがって、通常は、ワイヤーを介してシリアル化できるDTOを設計します。このDTOは、すべてのデータをサーバーに戻し、さらにビジネスルールや処理を適用できます。

今まで使用する機会がなかったので、他の回答を検討するので、私はリポジトリパターンに精通していません。

以下は私の理解です。

TableGateWay / RowDataGateWay：このコンテキストでは、ゲートウェイは、各「ドメインオブジェクト」が各「ドメインオブジェクトゲートウェイ」にマッピングされている特定の実装を参照しています。たとえば、Personがある場合、ドメインオブジェクトPersonをデータベースに格納するPersonGatewayがあります。Person、Employee、Customerなどがある場合、PersonGateway、EmployeeGateway、およびCustomerGatewayがあります。各ゲートウェイには、そのオブジェクトに固有のCRUD関数があり、他のゲートウェイとは何の関係もありません。ここには再利用可能なコード/モジュールはありません。ゲートウェイは、「id」または「オブジェクト」を渡すかどうかに応じて、RowDataGatewayまたはTableGatewayにさらに分割できます。ゲートウェイは通常、アクティブレコードと比較されます。ドメインモデルをデータベーススキーマに関連付けます。

Repository / DataMapper / DAO：それらは同じものです。これらはすべて、データベースエンティティをドメインモデルに転送する永続層を指します。ゲートウェイとは異なり、Repository / DataMapper / DAOは実装を隠します。Personの背後にPersonGatewayがあるかどうかはわかりません。気にしないかもしれませんし、気にしないかもしれません。ご存じのとおり、ドメインオブジェクトごとにCRUD操作がサポートされている必要があります。データソースとドメインモデルを分離します。