デザインパターンのスキルを磨こうとしていますが、これらのパターンの違いは何ですか?それらはすべて同じもののように見えます。特定のエンティティのデータベースロジックをカプセル化して、呼び出し元のコードが基礎となる永続化レイヤーの情報を持たないようにします。私の簡単な調査から、それらのすべては通常、標準の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オブジェクトを取得する予定です)が、意図/意味および結果の実装が異なります。
A Repository"acts like a collection, except with more elaborate querying capability" [ Evans, Domain Driven Design ] and may be considered as an "objects in memory facade" ( Repository discussion )
A DataMapper"moves data between objects and a database while keeping them independent of each other and the mapper itself" ( Fowler, PoEAA, Mapper )
A TableDataGateway is "a Gateway (object that encapsulates access to an external system or resource) to a database table. One instance handles all the rows in the table" ( Fowler, PoEAA, TableDataGateway )
A DAO"separates a data resource's client interface from its data access mechanisms / adapts a specific data resource's access API to a generic client interface" allowing "data access mechanisms to change independently of the code that uses the data" ( Sun Blueprints )
リポジトリは非常に汎用的であり、データベースの相互作用の概念を公開していません。 DAOは、さまざまな基礎となるデータベース実装を使用できるようにするインターフェイスを提供します。 TableDataGatewayは、具体的には単一のテーブルの薄いラッパーです。 DataMapperは、モデルオブジェクトがデータベースの表現とは独立して(時間とともに)進化できるようにする仲介役として機能します。
ソフトウェア設計の世界では、(少なくともそうだと思いますが)よく知られている古いものやパターンの新しい名前を発明する傾向があります。そして、新しいパラダイム(おそらく既存のものとわずかに異なる)がある場合、通常は各層に新しい名前のセット全体が付属します。したがって、「ビジネスロジック」は、SOAを行うというだけで「サービスレイヤー」になり、DAOはDDDを行うと言うだけでDAOをリポジトリにします(これらはそれぞれ、実際にはまったく新しいものではなく、新しい名前です。同じ本に集められた既知の概念について)。ですから、これらの現代のパラダイムや頭字語がまったく同じことを意味していると言っているわけではありませんが、あなたは本当にそれについて過度に偏執的であってはなりません。ほとんどの場合、これらは同じパターンであり、異なるファミリーからのものです。
Data Mapper vs Table Data Gateway 簡単に言うと:
最終的には、両方ともインメモリオブジェクトとデータベース間の仲介役として機能します。
良い点があります。最もよく知っているものを選んでください。私は明確にするのに役立つかもしれないいくつかのことを指摘するのが好きです。
テーブルデータゲートウェイは、主に単一のテーブルまたはビューに使用されます。すべての選択、挿入、更新、および削除が含まれます。したがって、顧客はあなたの場合のテーブルまたはビューです。したがって、テーブルデータゲートウェイオブジェクトの1つのインスタンスがテーブル内のすべての行を処理します。通常、これはデータベーステーブルごとに1つのオブジェクトに関連しています。
一方、Data Mapperはドメインロジックからより独立しており、結合度は低くなっています(ただし、結合があるかどうかは信じています)。オブジェクトとデータベースの間でデータを転送し、それらを互いに、マッパー自体から独立させたままにするのは、単なる中間層です。
そのため、通常、マッパーには挿入、更新、削除などのメソッドがあり、テーブルデータゲートウェイにはgetcustomerbyId、getcustomerbyNameなどがあります。
データ転送オブジェクトは、主に上記の2つのパターンのようなデータソースパターンではなく、分布パターンであるため、上記の2つのパターンとは異なります。主にリモートインターフェイスを使用していて、各通話が高価になる可能性があるため、通話のチャットを少なくする必要がある場合に使用します。そのため、通常、有線でシリアル化できるDTOを設計します。これにより、すべてのデータをサーバーに戻し、さらにビジネスルールや処理を適用できます。
これまで使用する機会がなかったので、他の回答を見るので、リポジトリパターンに精通していません。
以下は私の理解です。
TableGateWay/RowDataGateWay:このコンテキストでは、ゲートウェイは、各「ドメインオブジェクトゲートウェイ」への各「ドメインオブジェクト」マッピングを持つ特定の実装を参照しています。たとえば、Personがある場合、PersonGatewayがありますドメインオブジェクトPersonをデータベースに保存します。 Person、Employee、Customerなどがある場合、PersonGateway、EmployeeGateway、およびCustomerGatewayがあります。各ゲートウェイには、そのオブジェクトに固有のCRUD機能があり、他のゲートウェイとは関係ありません。ここには再利用可能なコード/モジュールはありません。ゲートウェイは、「id」または「object」を渡すかどうかに応じて、RowDataGatewayまたはTableGatewayにさらに分割できます。通常、ゲートウェイはアクティブレコードと比較されます。ドメインモデルをデータベーススキーマに結び付けます。
リポジトリ/ DataMapper/DAO:それらは同じものです。これらはすべて、データベースエンティティをドメインモデルに転送する永続層を参照します。ゲートウェイとは異なり、Repository/DataMapper/DAOは実装を隠します。 Personの背後にPersonGatewayがあるかどうかはわかりません。あなたは気にしないかもしれませんし、そうでないかもしれません。知っているのは、各ドメインオブジェクトに対してCRUD操作がサポートされている必要があるということだけです。データソースとドメインモデルを分離します。