0

次のオブジェクトモデルを検討してください（->>はコレクションを示します）。

顧客->注文

Orders->> OrderLineItems-> Product {Price}

アプリは注文の処理に重点を置いているため、特定の基準に一致するすべての注文を示すほとんどのタイムテーブルがUIで使用されます。99％の時間、私はLineTotalsの合計のみを表示することに関心があり、個々のLineTotalsは表示しません。

さらに考えてみると、各注文に複数の支払い（電信送金、小切手、クレジットカードなど）が関連付けられている可能性があります。これも、受け取った金額の合計にのみ関心があります。

データベースに注文を照会するとき、すべての注文を選択してから、注文ごとにその支払いとLineItemを選択したくありません。

私のアイデアは、各注文を「ステータス」オブジェクトに関連付けて保存し、注文のすべての合計とステータスをキャッシュし、桁違いにクエリのパフォーマンスを向上させ、未払いの注文、有料の注文、未払いの注文などのクエリシナリオをサポートすることでした。

これにより、ドメインロジック（注文が支払われたと見なされる場合など）がデータベースクエリにリークするのを防ぎます。ただし、合計を最新の状態に保つ責任があります。システムには通常、支払いの入力または統合、注文の作成/変更など、それが発生する必要がある明確に定義されたポイントがあります。

これまで、アイテムが追加または削除されたとき、またはアイテムの特定のプロパティが更新されたときにステータスの再計算をトリガーするObservableCollectionsを使用してきました。私は、dddの観点からすべての論理をどこに置くべきかを自問します。すべてのイベントワイヤリングと計算ロジックを集約ルートに強制するのは奇妙に思えます。

4

3 に答える 3

1

リポジトリがあなたが何をしたいのかを正確に理解し、それに応じて反応できるように、意図を明らかにするインターフェースでリクエストの意図を表現する必要があります。この場合、インターフェースは、他の開発者ではなく、他のコードに意図を明らかにします。したがって、ステータスまたは合計が必要な場合は、このインテントを明らかにするインターフェースを作成し、リポジトリーからそのタイプのオブジェクトを要求してください。次に、リポジトリは、合計を計算するために必要な作業を正確に実行することをカプセル化するドメインオブジェクトを作成して返すことができます。

さらに、DALは、要求するインターフェイスから適用するフェッチ戦略をインテリジェントに選択できます。つまり、子オブジェクトにアクセスする必要がない状況での遅延読み込みや、アクセスする場所での積極的な読み込みです。

Udi Dahanには、これに関するすばらしいブログ投稿がいくつかあります。彼は、この問題に意図を明らかにするインターフェースを適用することについて書いたり話したりしました。

于 2009-09-03T22:55:18.723 に答える
0

LINQ をサポートする OR (オブジェクト リレーショナル) マッパーを調べることを強くお勧めします。主要な 2 つの名前を挙げると、LINQ to SQL と Entity Framework で、どちらも Microsoft のものです。現在、LLBLGen も LINQ をサポートしていると思います。nHibernate には、試すことができる中途半端な LINQ ソリューションがいくつかあります。私の一番の推奨は、.NET 4.0 ベータ版または Visual Studio 2010 ベータ版から入手できる Entity Framework v4.0 です。

LINQ 対応の OR マッパーを使用すると、ドメイン モデルのみを使用して、必要な集計情報を動的かつリアルタイムで簡単にクエリできます。通常、ストアド プロシージャは使用しないため、ビジネス ロジックがデータ層に漏れる必要はありません。OR マッパーは、パラメーター化された SQL をその場で生成します。OR マッパーと組み合わせた LINQ は非常に強力なツールであり、エンティティとエンティティ グラフをクエリして取得するだけでなく、ドメイン モデルのデータ プロジェクションをクエリして、カスタム データ セットや集計などを取得することもできます。単一の概念モデルを介して。

于 2009-08-27T06:56:59.640 に答える