一般的な文字列を返す代わりに、従来のオブジェクトを返す方法はありますか? そうでない場合: ベスト プラクティスは何ですか? オブジェクトを xml に転置し、反対側でオブジェクトを再構築しますか? 他の可能性は何ですか?
11 に答える
前述のように、シリアライゼーションを介して .net でこれを行うことができます。デフォルトでは、すべてのネイティブ型はシリアライズ可能であるため、これは自動的に行われます。
ただし、複雑な型がある場合は、オブジェクトを [Serializable] 属性でマークする必要があります。プロパティとしての複雑な型にも同じことが言えます。
たとえば、次のものが必要です。
[Serializable]
public class MyClass
{
public string MyString {get; set;}
[Serializable]
public MyOtherClass MyOtherClassProperty {get; set;}
}
オブジェクトを XML にシリアル化でき、WSDL で記述できる場合は、Web サービスからオブジェクトを返すことができます。
はい: .NET では、このシリアル化を呼び出します。オブジェクトは XML にシリアル化され、消費するサービスによって元のオブジェクト型または同じデータ構造を持つサロゲートに再構築されます。
可能であれば、オブジェクトを XML に転置します。これは、Web サービスの移植性が高いことを意味します。その後、任意の言語でサービスにアクセスできます。その言語でパーサー/オブジェクト トランスポーザーを作成するだけで済みます。
サービスを記述した WSDL ファイルがあるため、一部のシステムではこれがほぼ自動化されています。
(たとえば、C で記述されたサーバー、C++/gSOAP で記述されたクライアント、および Cocoa/Objective-C で記述されたクライアントを置き換える純粋な python で記述されたサーバーがあります。テスト フレームワークとして soapUI を使用します。 Javaで書かれています)。
XML を使用して、Web サービスからオブジェクトを返すことができます。しかし、Web サービスは、プラットフォームやオペレーティング システムにとらわれないはずです。オブジェクトをシリアル化すると、ファイルなどのバイト ストリームからオブジェクトを格納および取得できるようになります。たとえば、Java オブジェクトをシリアル化し、そのバイナリ ストリームを (おそらく Base 64 エンコーディングを介して CDATA フィールドに) 変換し、それをサービスのクライアントに転送できます。
ただし、クライアントがそのオブジェクトを復元できるのは、それが Java ベースの場合だけです。さらに、オブジェクトをシリアライズして正確に復元するには、ディープ コピーが必要です。ディープ コピーはコストがかかる場合があります。
最善の方法は、ドキュメントを表す XML スキーマを作成し、オブジェクトの詳細を使用してそのスキーマのインスタンスを作成することです。
.NET は、シリアル化可能なオブジェクトでこれを自動的に行います。Javaも同じように機能すると確信しています。
.NET でのオブジェクトのシリアル化について説明している記事は次のとおりです: http://www.codeguru.com/Csharp/Csharp/cs_syntax/serialization/article.php/c7201
@Brian: Java でどのように動作するかはわかりませんが、.net オブジェクトは base64 文字列ではなく、XML にシリアル化されます。Web サービスは、Web サービスに必要なメソッドとオブジェクトの定義を含む wsdl ファイルを発行します。
単純に base64 文字列を作成する Web サービスを誰も作成しないことを願っています
Daniel Auger:
他の人が言ったように、それは可能です。ただし、サービスとクライアントの両方が、両側でまったく同じドメイン動作を持つオブジェクトを使用している場合は、おそらく最初からサービスは必要ありませんでした。lomax: やや狭いコメントなので、これには反対しなければなりません。ドメイン オブジェクトを XML にシリアル化できる Web サービスを使用すると、クライアントが同じドメイン オブジェクトを簡単に操作できるようになりますが、これらのクライアントは、公開した特定の Web サービスの使用に制限され、他の Web サービスでも動作することになります。逆に、他のクライアントがドメイン オブジェクトを認識していなくても、XML を介してサービスとやり取りできるようにします。
@ Lomax: あなたは 2 つのシナリオを説明しました。シナリオ 1:クライアントは、xml メッセージをまったく同じドメイン オブジェクトに戻しています。私はこれを「物を返す」と考えています。私の経験では、これは悪い選択であり、以下で説明します。シナリオ 2:クライアントが xml メッセージをまったく同じドメイン オブジェクト以外のものに再水和します。私はこれに 100% 賛成していますが、これがドメイン オブジェクトを返すとは考えていません。本当にメッセージまたは DTO を送信しています。
ここで、Web サービス全体での true/pure/not DTO オブジェクトのシリアル化が通常悪い考えである理由を説明します。アサーション: 最初にこれを行うには、クライアントとサービスの両方の所有者になるか、使用するライブラリをクライアントに提供して、オブジェクトを元の型に戻す必要があります。問題: タイプとしてのこのドメイン オブジェクトは現在、2 つの半関連ドメインに存在し、それらに属しています。時間の経過とともに、一方のドメインでは意味をなさない動作をもう一方のドメインに追加する必要が生じる場合があり、これは汚染や潜在的に苦痛な問題につながります。
私は通常、デフォルトでシナリオ 2 を使用します。圧倒的な理由がある場合にのみ、シナリオ 1 を使用します。
最初の返信でとても簡潔になってしまったことをお詫びします。これで、私の意見がある程度明確になることを願っています。ロマックス、私たちは半分同意しているようです;)。
JSON は、Web 上でオブジェクトを (javascript のサブセットとして) 渡すための非常に標準的な方法です。多くの言語は、JSON コードをネイティブ オブジェクトに変換するライブラリを備えています。たとえば、Pythonのsimplejsonを参照してください。
JSON を使用するその他のライブラリについては、JSON の Web ページを参照してください。
他の人が言っているように、それは可能です。ただし、サービスとクライアントの両方が、両側でまったく同じドメイン動作を持つオブジェクトを使用している場合は、そもそもサービスは必要なかった可能性があります。
やや狭いコメントなので、私はこれに反対しなければなりません。ドメインオブジェクトをXMLにシリアル化できるWebサービスを使用すると、同じドメインオブジェクトを操作するクライアントが簡単になりますが、それらのクライアントは、公開した特定のWebサービスの使用に制限され、他のクライアントがドメインオブジェクトを認識していなくても、XMLを介してサービスと対話できるようにすることで逆になります。
他の方がおっしゃる通り、可能です。ただし、サービスとクライアントの両方が、両側でまったく同じドメイン動作を持つオブジェクトを使用している場合、そもそもサービスはおそらく必要ありませんでした。