0

DDDから : ソフトウェアの中心にある複雑さに取り組む( pg. 177 ):

処理イベントを追加するときに配送履歴を更新する必要があるため、貨物の AGGREGATE がトランザクションに関与します。

a）ページのさらに下の作成者は代替ソリューションを提案しますが、それでも-上記の抜粋の作成者は、このプロパティがアクセスされるたびに（リポジトリを介して）データベースにプロパティクエリを実行することにより、関連付けを実装することを本質的に提案していませんか？DeliveryHistory.Events

b) 著者によって「提案された」実装は、遅延読み込みの実装方法とほぼ同じであるため (遅延読み込みは、最初にデータが必要になったときにのみクエリを実行し、それをキャッシュすることを除いて)、次のことも尋ねます。

多くの人は一般的に遅延読み込みに反対していますが、関連するエンティティが同じ集計内に存在する場合は、遅延読み込みを使用すべきではないと思います。

集計が変更されたときに不変条件を適切に適用できないため、関連するデータがアクセスされない場合 (したがって、取得されない場合)、この整合性が損なわれる可能性があるという理由は?

アップデート：

a)

DeliveryHistory.Events コレクションは、DeliveryHistory エンティティがリポジトリによって読み込まれるときに読み込まれます。遅延読み込みを介して読み込むこともできます。この場合、ORM は、反復時にデータベースを呼び出すコレクション プロキシを挿入します。

しかし、作成者は、 がアクセスされるたびに (またはおそらく が呼び出されるたびに)イベントを照会するという 3 番目のオプションを提案していませんか?DeliveryHistory.EventsDeliveryHistory.GetEvents()

b)

これは遅延読み込みに似ていますが、重要な違いは、リポジトリ クエリを使用すると、オブジェクト モデルの Events プロパティを省略できることです。これにより、DeliveryHistory エンティティの「フットプリント」が削減されます。

私は-「遅延読み込みに似ている」とは、イベントが要求されるたびにデータベースからイベントが取得される設計を指していると思いますか?!

II - とにかく、DeliveryHistory.Eventsプロパティを省略した場合 (おそらく a の代替として定義しない場合DeliveryHistory.GetEvents())、作成者によって提案された設計をどのように実装しますか (元の投稿で述べたように、ページ作成者のさらに下にあることを認識しています)より良い代替案を提案しましたか？

ありがとうございました

4

1 に答える 1

1

a) DeliveryHistory.EventsDeliveryHistory エンティティがリポジトリによって読み込まれると、コレクションを読み込むことができます。遅延読み込みを介して読み込むこともできます。この場合、ORM は、反復時にデータベースを呼び出すコレクション プロキシを挿入します。

b) 遅延読み込みに似ていますが、重要な違いは、リポジトリ クエリを使用すると、オブジェクト モデルの Events プロパティを省略できることです。DeliveryHistoryこれにより、エンティティの「フットプリント」が削減されます。

遅延読み込みの問題は、データにアクセスできないことではなく、遅延読み込みされたプロパティに初めてアクセスするとデータベース呼び出しが発生し、接続がまだ有効であることを確認する必要があることです。ある意味では、これは全体として考えられる集合体の完全性を損なう可能性があります。

アップデート

a) どちらの方法でも最終的な結果は同じです。プロキシ コレクションの作成が、この本が書かれたとき (2003 年) に使用された手法であったかどうかはわかりません。

b1) はい、イベントが DeliveryHistory エンティティと一緒に読み込まれるのではなく、オンデマンドでのみ読み込まれるという点で似ています。

b2) DeliveryHistory エンティティのイベント プロパティの代わりに、リポジトリを呼び出してイベントにアクセスします。リポジトリ自体は、周囲のアプリケーション サービスによって呼び出されます。イベントを取得し、それらを必要とする場所に渡します。または、ユースケースがイベントを追加する場合、アプリケーション サービスはリポジトリを呼び出してイベントを永続化します。

于 2013-02-06T22:59:10.397 に答える