ASMX使用コンパイルタイプの代わりに、生成されたタイプは、SoapHeaderは

Question

のために私は、SOAPヘッダのあまり働いていないので、私はここに答えがあります願っています。ここに私が達成しようとしているものの簡単な例があります。

私は、共有DLLと一緒に、ASMX Webサービスとクライアントを持っています。 shared.dllには、シリアライズ可能な型があり、それをCustomHeaderと呼びましょう。これはSoapHeaderから派生しています。 SoapHeader属性を介してこれを入力として受け入れるWebメソッドがあるので、私のサービスは次のようになります。

[WebService] 
public class MyService : WebService { 
    public CustomHeader MyCustomHeader { get; set; } 

    [WebMethod] 
    [SoapHeader("MyCustomHeader", Direction = SoapHeaderDirection.In)] 
    public void Go() { } 
} 

これまでのところ、とても良いです。 Go（）メソッドの中で、私はMyCustomHeaderオブジェクトにアクセスし、それを使って処理を行うことができます。クライアントから、プロキシを生成すると、生成されたコードには、MyServiceオブジェクトのデータプロパティを含むCustomHeaderクラスと、Go（）へのサービスコールを行う前にクライアントで設定できるCustomHeaderValueというプロパティが含まれています。それはちょうどそれに沿ってそれを渡す。

問題は、元のCustomHeaderクラスは、データ・フィールド（ハッシュ関数、計算値、など）を移入するのに役立ったコンストラクタとメソッドを持っていたことです。クライアントは共有ライブラリへの参照を持っているため、クライアントは元のCustomHeaderクラスのインスタンスを作成できますが、技術的に異なるタイプなのでサービス呼び出しでそのオブジェクトを使用することはできません。

私はこれを処理するいくつかの方法を考えることができます。

1）が一度に一つ上の特性を引っ張って生成されたCustomHeaderクラスにCustomHeaderオブジェクトに変換します。これはあまり処理されませんが、プロパティをループするためにリフレクションを使用するか、CustomHeaderクラスが変更されるたびにコンバージョンコードに触れる必要があることを意味します。

2）CustomHeaderオブジェクトをシリアライズし、生成されたCustomHeaderクラスにデシリアライズします。これらはコンストラクタやメソッドとはまったく同じであるため、シリアル化はうまく動作します。これは最も簡単な方法ですが、非常に高価ではありませんが、さらに処理が必要なシリアル化/デシリアライズが必要です。

3）は私の共有タイプの代わりに、生成されたタイプのCustomHeaderValueプロパティを作るために生成されたコードを変更します。私の意見は、これは恐ろしいことだと思っていますが、おそらくこれらのオプションの中で最もコストがかかりません。私はこのオプションを行うつもりはありませんが、技術的にうまくいくので、そこに書きたいと思っています。

何か不足していますか？これを行うための受け入れられたパターンがありますか？

ありがとうございました。

Answer 1

ASMX Webサービスは、クライアントとサービスとの間の型の再利用をサポートしていません。

WCFがこれをサポートしています。