3

いくつかの WCF サービスを作成しました。引数として、それらはService1およびService2と呼ばれます。

どちらのサービスも (ある時点で、おそらくオブジェクト内の関係を通じて) Customerオブジェクトを返します。

テストのために、Service1 と Service2 の両方にGetCustomer()メソッドを追加し、基本的な WinForms アプリケーションで両方のサービスへのサービス参照を追加しました。

Service1Client proxy1 = new Service1Client();

顧客 customer1 = proxy1.GetCustomer(); ///

^^^^^^ あいまいな参照です。WcfTestClient.Service1.Customer という名前にする必要があります。

Service2Client proxy2 = 新しい Service2Client();

顧客 customer2 = proxy2.GetCustomer();

^^^^^ あいまいな参照です。WcfTestClient.Service2.Customer という名前にする必要があります。

問題は、Service1とService2によって返される Customer オブジェクトが両方とも同じ種類の Customer (WcfTestService.Customer) であることです。これを解決するには、Customer だけでなく完全なアセンブリ名を含める必要があります。

データ コントラクトを別のアセンブリにコンパイルできるというスタック オーバーフローに関する投稿をいくつか読みましたが、Java などの他の言語を使用しているクライアントで問題が発生する可能性があるため、この考えは特に好きではありません。

私が見た別の解決策は SvcUtil.exe メソッドですが、各サービスの Util を個別に実行する必要があるため、この解決策は名前空間の問題に対処していません。

誰かが役に立つ提案を持っている場合は、連絡してください!

4

1 に答える 1

4

どちらのサービスも (ある時点で、おそらくオブジェクト内の関係を通じて) Customer オブジェクトを返します。

ここが間違っているところです。WCF はオブジェクトを返さず、REST はオブジェクトを返さず、SOAP はオブジェクトを返しません。それらはすべてメッセージを渡します。

Web サービスへの参照を追加すると、Visual Studio は喜んでこれらのメッセージのラッパー クラスを作成し、その内容をプロパティとして公開します。2 つのサービスを追加しているため、これらのラッパー クラスは互いを認識していないため、最終的に 2 つの名前空間と 2 つのラッパー クラスが作成されます。

はい、あなたが言うように、メッセージクラスを別のアセンブリに移動し、それをリンクして参照の追加を回避すると、適切なオブジェクトとして機能しますが、それでも舞台裏でメッセージが渡され、シリアル化され、この共有オブジェクトに逆シリアル化されます。オブジェクトの受け渡しの観点から考えるのをやめて、メッセージの観点から考え始めると、2 つのラッパー オブジェクトで行き詰まっているか、外部アセンブリをリンクする必要があることに気付くでしょう。

于 2010-01-26T14:36:31.307 に答える