22

例：データベースに「CustomerOrdersOnHold」という名前のSQLビューがあります。このビューは、特定の顧客データフィールドと注文データフィールドのフィルタリングされた組み合わせを返します。アプリケーションのこのビューからデータをフェッチする必要があります。このようなビューへのアクセスは、リポジトリパターンにどのように適合しますか？「CustomerOrdersOnHoldRepository」を作成しますか？このような読み取り専用ビューは集約ルートと見なされますか？

4

3 に答える 3

31

読み取りリポジトリを分離することをお勧めします。できればその名前を Finder または Reader に変更することもできます。リポジトリは、読み取り専用データをクエリするためではなく、ドメインで使用するためのものです。 .

読み取りモデルを書き込みモデル アーキテクチャCQRSから分離することもお勧めします。

このアーキテクチャにより、データ ストレージとイベント ソーシングの使用に関しても、読み取りモデルを書き込みモデルから分離できます。

中間のソリューションについては、リポジトリをファインダーから分離するだけでデータベースを分離する複雑さなしに、いくつかの CQRS の概念を利用できます。この投稿を読んでください。

このタイプのソリューションのサンプル (同じデータベースを使用しますが、リポジトリからファインダーを分離します) については、このサンプルを確認してください

于 2011-09-11T12:05:10.213 に答える
0

「CustomerOrdersOnHoldRepository」のように別途レポジトリを用意しても良いと思います。リポジトリのインターフェースは、オブジェクトが読み取り専用であるという事実を反映します (Save/Add/MakePersistent メソッドを定義しないことにより)。

リポジトリの書き方から:

... しかし、私が非常に気に入っている別の戦略があります: 複数のリポジトリです。この注文の例では、AllOrders と SurchargedOrders の 2 つのリポジトリを使用できる理由はありません。AllOrders はシステム内のすべての注文を含むリストを表し、SurchargedOrders はそのサブセットを表します。

返されたオブジェクトを集約ルートとは呼びません。集約は、一貫性、データ交換、およびライフサイクルのためのものです。オブジェクトにはこれらのいずれもありません。また、値オブジェクト (「特性または属性」) として分類できないようです。それらは単なるスタンドアロンのクラスです。

于 2011-09-09T19:03:32.540 に答える
0

読み取り専用データは、DDD の世界では値オブジェクトと見なされます。

私は通常、別のリポジトリを作成することが理にかなうまで、値オブジェクトのアクセス メソッドを既存のリポジトリに配置します。これは、住所フォームで使用される州の静的リストを返すメソッドに似ています。

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}
于 2011-09-09T20:18:04.203 に答える