2009-06-12 10 views
1

私は、Webサービスコールで抽象クラスをパラメータとして使用しています。現在、私のようなので、基本クラスの派生クラスのXmlIncludeを含めています:Webサービス - ベースクラスではなく派生クラスのXmlInclude?

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

しかし、私はむしろ、基本クラスに派生型のすべてが含まれていないと思います。 http://www.pluralsight.com/community/blogs/craig/archive/2004/07/08/1580.aspx

、著者は代替言及 - そのように、代わりにWebメソッドの上に属性を書き込ん:しかし、私はまた、いずれかのWebサービスに派生型を入れていないしたいと思います

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

を。派生型に属性を保持する方法はありますか?

答えて

4

デシリアライゼーションが発生したときにどのような型が型検索にあるのか、そして型がxmlでどのように表現されているかを、フレームワークが何とか知る必要があることを考えてください。派生型に格納されている場合、この情報を推論する方法は実際にはありません。

あなたはその後、オプションのカップルを持っている: は - XmlInclude属性 を使用する - あなたはに渡されるサブクラスを期待している場合のXmlSerializerコンストラクタで許可されるタイプのセットを指定し、今

をオーバーロードwebserviceは、Webサーバがシリアライゼーションとデシリアライゼーションを制御します。したがって、XmlSerializerコンストラクタはもはやオプションではありません。

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

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

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

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

最後に、Webサービスは、期待する型を知る必要があります。そうしないと、適切にシリアル化してデシリアライズできなくなります。

これは答えが「いいえ」である理由の長い説明です。派生型の属性を保持するだけでは不十分です。私は間違っていることを愛するだろう:)

2

私はこの場合どのように表示されません。デシリアライズしている場合は、派生型を渡す余分な型配列を指定するオーバーロードがあります。

関連する問題