3

DDDを見ると、データベースを操作するさまざまなモデルに抽象化し、モデルが存在するリポジトリとして見ています。次に、その上にデータレイヤーとサービス/ビジネスレイヤーを追加します。私の質問は、そうすることで、脂肪モデルを構築することによってデータ転送の非効率性を生み出しているのでしょうか？

たとえば、顧客の請求書を画面に表示するシステムがあるとします。OOPの観点から考えると、おそらく次のようなオブジェクトになります。

class Invoice {
    Customer _customer;
    OrderItems _orderitems;
    ShippingInfo _shippingInfo;
}

class Customer {
    string name;
    int customerID;
    Address customerAddress;
    AccountingInfo accountingInfo;
    ShoppingHistory customerHistory;
}
    (for the sake of the question/argument, 
    let's say it was determined that the customer class had to 
    implement AccountingInfo and ShoppingHistory)

請求書に顧客名のみを印刷する必要がある場合、他のすべての手荷物を一緒に運ぶのはなぜですか？リポジトリタイプのアプローチを使用すると、これらすべてのリソース（CPU、メモリ、複雑なクエリ結合など）を必要とするこれらの複雑なドメインオブジェクトを構築し、それをチューブを介してクライアントに転送するように見えます。

単にcustomerNameプロパティを請求書クラスに追加することは、抽象化から脱却し、恐ろしい慣習のように思えます。一方、Customerのようなオブジェクトを半分埋めるのは、同じオブジェクトの複数のバージョンを作成する可能性があるため、非常に悪い考えのように思われます（たとえば、Addressはあるが、ShoppingHistoryはないもの、AccountingInfoはあるが住所等）。何が欠けているのか、理解していないのですか？

4

2 に答える 2

1

優れたオブジェクト リレーショナル マッパーはリレーションシップを遅延読み込みできるため、請求書のために顧客を引き戻すことはできますが、顧客の会計と買い物の履歴は無視します。オブジェクト リレーショナル マッパーを使用していない場合は、自分で作成できます。

多くの場合、クライアント内でこれを行うことはできません。これは、トランザクションの境界を越えている (データベースのトランザクションが終了している) ため、適切なデータがロードされていることを確認するのはサービス レイヤー次第です。

適切なデータが利用可能であること (そしてそれほど多くないこと) をテストすることは、多くの場合、サービス レイヤーでの単体テストで行うのに適しています。

于 2009-07-18T18:27:13.300 に答える
0

「顧客クラスはAccountingInfoとShoppingHistoryを実装する必要があると判断された」と言うので、請求書を明確に表示することだけがシステムが実行するタスクではありません（顧客が他の機能を必要とすることは他にどのように「決定」されましたか？-） 。

したがって、とにかく（他の機能のために）顧客のテーブルが必要です。もちろん、請求書プリンターは、システムの他の機能で使用されているものと同じ、その1つのテーブルから顧客データ（名前だけでも）を取得する必要があります。

したがって、「オーバーヘッド」は純粋に幻想的です。1つの機能を分離して見ると存在するように見えますが、システム全体を統合された全体として見るとまったく存在しません。

于 2009-07-18T18:14:25.820 に答える