139

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

これは、データマッパーパターンとリポジトリパターンの場合と同じ原則のようです。DAOパターン（ゲートウェイと同じだと思いますか？）も、データベース固有のゲートウェイを促進しているようです。

私は何かが足りないのですか？同じことを3〜4つの異なる方法で行うのは少し奇妙に思えます。

4

5 に答える 5

101

あなたの例の用語; DataMapper、DAO、DataTableGateway、Repository はすべて似たような目的を持っていますが (私が使用した場合、Customer オブジェクトが返されることを期待しています)、意図/意味と結果の実装は異なります。

リポジトリ は「より精巧なクエリ機能を除いて、コレクションのように機能します」 [ Evans 、ドメイン駆動設計]、 「メモリファサード内のオブジェクト」と見なすことができます(リポジトリの議論)

DataMapperは、 「オブジェクトとデータベースの間でデータを移動し、それらを互いに独立させ、マッパー自体から独立させます」 ( Fowler, PoEAA, Mapper )

TableDataGatewayは、「データベース テーブルへのゲートウェイ (外部システムまたはリソースへのアクセスをカプセル化するオブジェクト) です。1 つのインスタンスがテーブル内のすべての行を処理します」 ( Fowler, PoEAA, TableDataGateway )

DAO は、 「データ リソースのクライアント インターフェースをデータ アクセス メカニズムから分離し、特定のデータ リソースのアクセス API を汎用クライアント インターフェースに適合させ」、「データを使用するコードとは独立してデータ アクセス メカニズムを変更する」ことを可能にします( Sun Blueprints ) 。

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

于 2009-05-02T09:12:16.080 に答える
35

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

于 2009-05-02T08:41:33.017 に答える
34

Data Mapper と Table Data Gateway の 比較

  • Data Mapper は、ドメイン モデル オブジェクト (エンティティ) をパラメーターとして受け取り、それを使用して CRUD 操作を実装します。
  • テーブル データ ゲートウェイは、メソッドのすべてのパラメーターを (プリミティブとして) 受け取りますが、ドメイン モデル オブジェクト (エンティティ) については何も知りません。

    最終的に、それらは両方ともメモリ内オブジェクトとデータベースの間の仲介者として機能します。

    • 于 2013-06-24T14:41:50.777 に答える
    15

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

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

    一方、Data Mapper はドメイン ロジックからより独立しており、結合されていません (ただし、結合があるかどうかはわかりません)。オブジェクトとデータベースの間でデータを転送し、それらを互いに独立させ、マッパー自体から独立させておくのは、単なる中間層です。

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

    データ転送の対象が上記の 2 つのパターンと異なるのは、主に、上記の 2 つのパターンのようにデータ ソースのパターンではなく、分散のパターンであるためです。主に、リモート インターフェイスで作業していて、各通話の料金が高くなる可能性があるため、通話の煩わしさを軽減する必要がある場合に使用します。そのため、通常は、すべてのデータをサーバーに戻してさらにビジネス ルールを適用したり処理したりできるワイヤ経由でシリアル化できる DTO を設計します。

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

    于 2009-04-30T00:03:33.047 に答える