2

ページ上のデータの読み取り専用リストを生成する必要があり、そのデータが複数の、場合によっては 5 つ以上の異なるリポジトリから自然に取得される場合はどうしますか?

私たちは DDD を使用しており、リポジトリを介してデータベースへのアクセスを強制していますが、DDD に適合しないと思われるシナリオが発生し、使用する最適なパターンを決定しようとしています。

たとえば、ビデオ、フォーラム、ブログなどを含むコミュニティ ベースの Web サイトがあるとします。コメントのリストを含むフォーラム ページがあるとします。これは大雑把ですが、意味があることを願っています。

<table>
<tr><td>User Name (with possible link)</td><td>User's community score.</td><td>User Avatar</td><td>User's E-mail</td><td>User's blog</td><td>User's videos</td></tr>
</table>
<table>
<tr><td>This is a comment.</td></tr>
</table>

したがって、各コメントには、ユーザー名、コミュニティ スコア、アバター、電子メール、ユーザーのブログ、ユーザーのビデオ ページなど、いくつかの異なる部分が含まれます。従来、これらの情報はすべて別々のリポジトリから取得されていました。

その際の問題は効率です。リポジトリは最大化できますが、作成したアグリゲートの周りだけです。複数のリポジトリにあるデータにアクセスする必要がある場合、リポジトリを使用すると読み取りアクセスが非効率になります。

私の解決策は、関連情報を含む UserInformation DTO を作成し、署名付きの UserForumsRepository にメソッドを配置することです。 

ILIst<UserInformation> GetUserForumsUserInformationByForumPostID(int forumPostID).

私の同僚の 1 人は、この方法で DTO を使用すると、これまで使用してきた設計パターンが壊れ、より良い方法はフォーラム コメント ID のリストを取得し、それらの ID をさまざまなリポジトリに渡して、結果。

私自身の見解では、リポジトリの主な目的は CRUD の CUD 部分にとって重要なビジネス ロジックをカプセル化することですが、読み取り専用リストは最も理にかなった方法で生成する必要があります。必要に応じて、読み取り専用のリスト メソッドをリポジトリから完全に削除することも理にかなっていると思います (たとえば、複数の異なるタイプのページで使用される共通のウィジェットなど)。

この状況をどのように処理しますか？

4

2 に答える 2

1

答え 2

ここで必要なのは、具体的なリポジトリとクライアントの間の追加のサービス レイヤーです。クライアントが必要とするものは、特にリポジトリが分散されている場合に、リポジトリ層が提供するものとは異なる場合があります。サービス層を使用すると、粗粒度のメソッドを定義し、細粒度の詳細をクライアントから隠すことができます。サービス層を使用すると、本格的なビジネス オブジェクトではなく、軽量の DTO をクライアントに渡します。

ビジネス オブジェクトを DTO にマップしたり、その逆にマップしたりするために、ツール Automapper が非常に一般的になりつつあります。

于 2010-03-24T13:48:52.703 に答える
1

私は自分の質問に答えるのが嫌いですが、コメントはなく、いつもの容疑者であるファウラーから答えを見つけたようです.

最も単純な DDD と同じ設計では、アプリケーションはリポジトリに直接接続してデータを取得および更新します。ただし、より複雑なシナリオでは、具象リポジトリとアプリケーション層の間に追加のサービス層があります。オブジェクトをドメイン モデルからクライアントに渡す代わりに、DTO を渡します。

ファワー (PoEAA 401) によると、「. . . 通常、ドメイン モデルからオブジェクトを転送することはできません。. . . オブジェクトは通常、シリアル化が不可能ではないにしても困難な複雑な Web で接続されているためです。」Fowler 氏は続けて、「代わりに、ドメイン オブジェクトから簡略化された形式のデータを転送する必要があります」

実際、特に分散システムでは、DTO をクライアントに渡すのが標準です。サービス層がドメイン層からこれらの DTO を組み立てる方法は、クライアントにとって重要ではありません。

私は、ファウラーのこの発言に少し心を痛めていることを認めなければなりません。ASP.Net MVC でドメイン モデルを使用する利便性が非常に気に入っています。マスター/ディテール UI デザイン パターン ビューを作成する場合に特に便利です。厳密に型指定されたビューが顧客に関連付けられている場合、1 行のコードで CustomerOrders.ascx 部分ビュー (タイプ IList) を含め、customer.Orders を部分ビューに渡すだけです。ドメイン オブジェクトが動作しない限り、これを続けても問題ないかもしれませんが、それは今後の課題です。

于 2010-03-23T17:24:42.850 に答える