0

リクエストを受け入れ、リクエストタイプに基づいて処理するWCFサービスを開発しました。しかし、私は何よりもデザインの問題に出くわしました。ほとんどの要求と応答は非常に迅速かつ単純で、少量のデータが送受信されるため、これは標準のバッファードトランスポートモードに最適です。ただし、（サービスからクライアントに）大量のデータを返す可能性のあるリクエストタイプがいくつかあります。その場合、MaxRecievedMessageSizeを非常に高く設定するか、ストリーミングトランスポートモードに切り替える必要があります。

私は、個々のリクエストを設定し、ストリーミングされたリクエストに対して新しいコントラクト/バインディングなどを作成することが正しい方向であると確信しました。ただし、リクエストオブジェクト（リクエスト、そのタイプなどに関するコンテンツを保持する）を渡すのが好きで、これはデータコントラクトであるという課題に直面しています。ただし、ストリーミングトランスポートモードに変換する場合は、メッセージコントラクトを渡すという制限があります。

データコントラクトを拡張し、拡張されたクラスをメッセージコントラクトと呼ぶことはできますか？例えば：

[DataContract]    
public class RequestObject

[MessageContract]
ExtendedRequestObject : RequestObject

このルートに行けない場合、アーキテクチャがまだ理にかなっていることを確認するための最良の方法は何ですか？複数のパラメーターなどを持つ大量のメソッド/関数を使用する代わりに、常に1つのオブジェクトを渡して、そのオブジェクトの検証を実行できるのが好きでしたか？

4

1 に答える 1

2

ソースが見つかりませんでしたが、奇妙で不可能なようです。基本クラスのDataMembersはどのように扱われますか？

そして、継承は不要のようです。集約についてはどうでしょうか。

[MessageContract]
class ExtendedRequestObject
{
    [MessageBodyMember]  RequestObject Request;

}
于 2012-10-08T18:24:25.127 に答える