1

Webサービス呼び出しのパラメーターとして抽象クラスを使用しています。現在、次のように、派生クラスのXmlIncludeを基本クラスに含めています。

[XmlInclude(typeof(DerivedClass))]
public abstract class BaseClass
{
}

ただし、基本クラスにすべての派生型を含めたくはありません。

http://www.pluralsight.com/community/blogs/craig/archive/2004/07/08/1580.aspxで、作成者は別の方法について言及しています。代わりに、次のようにWebメソッドの上に属性を記述します。

[WebMethod]
[System.Xml.Serialization.XmlInclude(typeof(DerivedClass))]
public BaseClass getClass() {
     return new DerivedClass(); 
}

ただし、派生型もWebサービスに入れたくありません。派生型で属性を保持する方法はありますか？

4

2 に答える 2

4

フレームワークは、逆シリアル化が発生したときに型階層に含まれる型と、それらの型が xml でどのように表現されるかを何らかの方法で知る必要があることを前提として考えてみましょう。派生型に格納されている場合、この情報を推測する方法は実際にはありません。

- XmlInclude 属性を使用 - XmlSerializer コンストラクター オーバーロードで許可された型のセットを指定

ここで、サブクラスが Web サービスに渡されることを期待している場合、Web サーバーはシリアライゼーションとデシリアライゼーションを制御します。そのため、XmlSerializer コンストラクターはオプションではなくなりました。

あなたが言うように、クラスに直接ではなく、webservice メソッドに属性を配置できます。クラスを「純粋」に保つことと、必要なすべての場所にこれらの属性を配置することを忘れないこととの間には、トレードオフがあります。

もちろん、実際の問題は、Web サービス層でビジネス オブジェクトをメッセージ形式として使用しようとしていることにあるようです。

「メッセージ形式」と「ビジネスオブジェクト」の責任を分離したい場合は、Web サービスパラメーターとしてのみ使用される別のクラス (完全な階層を持つ) を用意してください。その場合、必要なすべての XmlInclude 属性を基本クラスに貼り付けても問題ありません。次に、Web サービスを呼び出すときに、ビジネス オブジェクトをメッセージ形式オブジェクトとの間で適合させます。これにより、パラメーターの型に webservice 型の制約を適用しないという追加の利点が得られます (たとえば、パラメーターとしてインターフェイスがない)。

もちろん、この方法はあまり便利ではありません。

最終的に、Web サービスはどのタイプが期待されるかを知る必要があります。そうしないと、適切にシリアライズおよびデシリアライズできません。

はい、これは答えがノーである理由の長い説明です。派生型に属性を保持することしかできません。私は間違っているのが大好きです:)

于 2009-06-13T07:22:26.060 に答える
2

この場合、どうすればよいかわかりません。逆シリアル化する場合は、派生型を渡す追加の型配列を指定するためのオーバーロードがあります。

于 2009-06-12T20:22:33.587 に答える