2

ビューに応じて、同じオブジェクトの複数の表現がある場合、どのように状況を解決しますか?

たとえば、あなたが本屋を経営しているとしましょう。書店内では、書籍の 2 つの主要な表現があります。

  1. リスト (検索結果、カテゴリ別の参照、作成者など): これは、NumberOfAuthors や NumberOfRwviews などの集計を含むコンパクトな表現です。各 Author と Review は、db に保存されたエンティティそのものです。
  2. DetailsView: ここでは、Book には AuthorsList プロパティがあるため、集計ではなく各 Author の実際の値があります。

ケース 2 はクリアです。DB からすべてを取得して表示します。しかし、ケース 1 を解決するにはどうすればよいですか。DB との間の接続とペイロードの数を減らしたい場合はどうすればよいでしょうか。したがって、DB からすべての実際の作成者とレビューを取得するのではなく、それぞれのカウントに 2 つの int だけを取得したい場合。

完全に正規化されたソリューションは 2 ですが、1 つは何らかの非正規化を必要とするか、ビジネス レイヤー内の BookDetails と BookCompact の 2 つの異なるエンティティを作成するようです。

重要: View DTO について話しているわけではありませんが、実際には Business Layer Book クラスに適合しない DB からデータを取得しています。

4

2 に答える 2

0

私にとっては、複数のクエリ モデル (QM) のように思えます。私は CQRS/ES スタイルで DDD を使用したため、集約ルートは、渡されたコマンドに基づいてイベントを生成しています。これらのイベントには、複数の QM がサブスクライブされています。そのため、要件に基づいて複数の「ビュー」を作成します。
ES (イベントソーシング) には大きな力があります。保存されたイベントを再生することで、後で別の QM を導入できます。
似たような、または重複したデータを大量に管理しているように聞こえますが、私には理にかなっています。
QM は、特定の目的に十分なデータ/構造/インデックスを含めるように最適化できます。これが「共有データモデル」から抜け出す方法です。「RDMS」ワン・フォー・オール・アプローチには巨大な悪が見えます。あなたと同じように、共有モデルの管理の複雑さに常に迷います。

于 2016-11-18T10:15:59.887 に答える
0

次の設計で非常に良い結果が得られました。

  • domainパッケージには@Entity、データベースに保存されるすべての必要なデータを含むクラスが含まれています

  • dtoサービスから返されるエンティティのビューを含むパッケージ

Dto には、エンティティをパラメーターとして受け取るコンストラクターが必要です。データを簡単にコピーするには、使用できますBeanUtils.copyProperties(domainClass, dtoClass);

これを行うことにより、最小限の情報のみを共有し、機能を持たないオブジェクトで返されます。

于 2016-11-25T15:35:46.280 に答える