12

サービスの参照データに使用する「最適な」パターンに関するフィードバック/オプション/コメントを求める。

参照データとはどういう意味ですか?

例として Northwind を使用してみましょう。Order は、データベース内の Customer に関連付けられています。注文サービスを実装するとき、注文から「完全な」顧客を参照する必要がある場合と、顧客 (キー/値のペアなど) への参照だけが必要な場合があります。

たとえば、GetAllOrders() を実行している場合、完全に入力された Order を返すのではなく、各注文の Customer の参照データのみを含む軽量バージョンの Order を返す必要があります。ただし、GetOrder() メソッドを実行した場合は、このメソッドのコンシューマーが必要とする可能性があるため、顧客の詳細を入力したいと思うでしょう。特定のメソッド呼び出し中に顧客の詳細を入力するように依頼したいが、他の状況では省略したい状況が他にもあるかもしれません。

これが私が思いついたものです：

[DataContract]
public OrderDTO
{
    [DataMember(Required)]
    public CustomerDTO;

    //etc..
}

[DataContract]
public CustomerDTO
{
    [DataMember(Required)]
    public ReferenceInfo ReferenceInfo;

    [DataMember(Optional)]
    public CustomerInfo CustomerInfo;
}

[DataContract]
public ReferenceInfo
{
    [DataMember(Required)]
    public string Key;

    [DataMember(Required)]
    public string Value;
}

[DataContract]
public CustomerInfo 
{
    [DataMember(Required)]
    public string CustomerID;

    [DataMember(Required)]
    public string Name;

    //etc....
}

ここでの考え方は、CustomerDTO では ReferenceInfo (一般的なキーと値のペア) が常に必要であるため、常に ReferenceInfo を保持するということです。後で必要に応じて顧客の詳細を取得するのに十分な情報が得られます。CustomerDTO に ReferenceInfo を要求することの欠点は、完全な CustomerDTO (つまり、CustomerInfo が入力された状態) を取得するときにやり過ぎになる可能性があることですが、少なくとも参照情報は保証されます。

このシナリオ/実装を「よりクリーン」にするために使用できる他のパターンまたはフレームワークの一部はありますか?

私が尋ねる理由は、Northwind では常に完全な CustomerDTO を返すように単純に言うことができますが、Northwind の単純な状況ではうまく機能する可能性があるからです。私の場合、参照/ルックアップ タイプのデータである 25 ～ 50 のフィールドを持つオブジェクトがあります。さまざまな状況で他のものよりもロードすることが重要なものもありますが、これらの参照型の定義をできるだけ少なくしたいと思います (「DTO メンテナンス地獄」に陥らないようにするため)。

意見？フィードバック？コメント?

ありがとう！

4

7 に答える 7

2

私たちは私たちのプロジェクトで同じ決定点にいます。現在のところ、Thingを処理するためにSimpleThing、ComplexThing、FullThingの3つのレベルのDTOを作成することにしました。しかし、それがどのように機能するかはわかりません。したがって、これはまだ現実に基づいた答えではありません。

私が疑問に思っていることの1つは、私たちのサービスが「間違った」レベルで設計されていることを知ることができるかどうかです。たとえば、FullThingを分解して、SimpleThingのみを渡す必要がある場合がありますか？もしそうなら、それは私たちが不適切にいくつかのビジネスロジックを高すぎるレベルに置いたことを意味しますか？

于 2009-07-09T19:48:07.393 に答える
2

Amazon Product Advertising API Web サービスは、あなたが経験している同じ問題の良い例です。

さまざまな DTO を使用して、発信者の状況に応じて多かれ少なかれ詳細を提供します。たとえば、小規模な回答グループ、大規模な回答グループ、中程度の回答グループがあります。

あなたが言うように、おしゃべりなインターフェイスが必要ない場合は、さまざまな DTO を使用することをお勧めします。

于 2009-09-18T11:37:45.350 に答える
1

私は通常、複雑な Web サービス (つまり、エンティティを送受信する Web サービス) に遅延読み込みを組み込みます。Person が Father プロパティ (Person でもある) を持っている場合、ネストされたオブジェクトではなく、Father の識別子のみを送信し、Web サービスに識別子を受け入れて対応する Person エンティティで応答できる操作があることを確認します。 . クライアントは、Father プロパティを使用する必要がある場合、Web サービスをコールバックできます。

また、バッチ処理が発生するように、これを拡張しました。オペレーションが 5 人の人物を送り返した場合、Father プロパティがそれらの人物のいずれかでアクセスされると、5 人の父親すべてとその識別子が要求されます。これにより、Web サービスのおしゃべりを減らすことができます。

于 2009-09-22T19:47:08.533 に答える
1

もう 1 つの可能性は、オブジェクトをプロパティ バッグとして扱うことです。クエリを実行するときに必要なプロパティを指定し、必要なプロパティを正確に取得します。

「短い」バージョンで表示するようにプロパティを変更すると、複数回のラウンドトリップが不要になり、セットのすべてのプロパティを一度に取得でき (おしゃべりなインターフェイスを回避)、データを変更したり、 「短い」バージョンに異なるプロパティが必要であると判断した場合は、操作コントラクト。

于 2009-07-25T04:19:04.520 に答える
1

オブジェクト リレーショナル マッピングでも、この問題に直面しました。完全なオブジェクトが必要な場合と、オブジェクトへの参照が必要な場合があります。

難しいのは、シリアル化をクラス自体に組み込むことによって、datacontract パターンが、オブジェクトをシリアル化する正しい方法は 1 つしかないという考えを強要してしまうことです。しかし、クラスやその子オブジェクトを部分的にシリアル化する必要があるシナリオはたくさんあります。

これは通常、クラスごとに複数の DTO が必要であることを意味します。たとえば、FullCustomerDTO と CustomerReferenceDTO です。次に、さまざまな DTO を Customer ドメイン オブジェクトにマップする方法を作成する必要があります。

ご想像のとおり、これは膨大な作業であり、そのほとんどは非常に退屈です。

于 2009-07-09T21:07:36.577 に答える
1

私には複雑な解決策のように思えます。OrderDTO クラスに顧客 ID フィールドを用意して、実行時に顧客データが必要かどうかをアプリケーションに判断させてはどうでしょうか。顧客IDを持っているため、決定したときにデータを引き出すことができます。

于 2009-06-16T23:29:15.120 に答える