0

新しい ServiceStack への参照を nuget から (3.9.11 からバージョン 3.9.56 に) 更新したところ、SOAP クライアントを動作させることができませんでした。そこで、[github] で提供されている Hello World ソリューション ( https://github.com/ServiceStack/ServiceStack.Examples/tree/master/src/ServiceStack.Hello ) をもう一度試すことにしましたが、これは古いバージョンを使用しています。 (3.9.32)。

クラスとクラス[DataContract]に属性を追加し、localhost soap12 エンドポイントにサービス参照を追加して C# コンソール クライアントを構築しようとしました (VS2010 で [サービス参照の追加] を使用し、2012 と 2013 も試しました)。残念ながら、 と を取得していますが、DTO は生成されません。何故ですか？以前のバージョンの ServiceStack でコードをビルドしようとしました ( メソッドと メソッドを使用して、すべて正常に動作しました! 認識していない重大な変更はありますか?HelloHelloResponseOneWayClientSyncReplyClientIService<T>Execute

PS私はナゲットライブラリに対してServiceStack.Examplesプロジェクト全体を再コンパイルしようとしましたが、それも失敗しました。プロキシを生成することさえできませんでした。私の DTO に共有アセンブリを使用するよう説得しようとしないでください。これは、言語にとらわれない Web サービスを提供する目的に反するからです。

4

2 に答える 2

3

私の DTO に共有アセンブリを使用するよう説得しようとしないでください。これは、言語にとらわれない Web サービスを持つという目的に反するからです。

物事を成し遂げる態度のようには聞こえません。サービスの目的が何だと思うかわかりませんが、複雑な WS-* 仕様 (これは死んでいます) を実装することではなく、独自のコード生成プロキシ ツール、特にコードを結合する RPC メソッド シグネチャを生成するものをなだめるためでもありません。 -gen 型を使用して、今日の Web サービス実装で使用されている技術の最も壊れやすい組み合わせを提供する、非効率的で肥大化した SOAP 形式の使用に限定されたプロキシ クライアントを生成します。

サービスの目的は、実際には... サービスを提供することです。いくつかの機能をカプセル化し、可能な限り最もアクセスしやすく、寛容で相互運用可能な方法で、理想的には労力、摩擦、複雑さを最小限に抑えて効率的に、リモートで利用できるようにすることです。

SOAP 生成プロキシが、言語にとらわれない Web サービスを実現するためのチケットであると考える理由がわかりませんか? code-gen プロキシの実装は、多くの場合、脆弱で不完全であり、企業内で人気のないプラットフォームでは推奨されていないことを考えると.

WSDL の全体的な目的は、コード生成プロキシが型付きサービス クライアントを生成するために使用できる機械可読仕様を提供することでした。これが WSDL (サービスではない) の目的です。サービスへの接続を提供します)。しかし、その複雑さとクローズド ソースのブラック ボックス ツールの下では、サーバー上で開発および管理されているクリーンな DTO 型を再作成することはまだできません。ただし、.dll (またはソース コード) を .NET クライアント プロジェクトにコピーするだけで、人為的な機構と複雑さをすべて回避できます。これにより、ServiceStack の汎用 .NET サービス クライアントのいずれかを使用できるサーバー DTO との対称パリティが得られます。汎用の型指定されたクライアントは代用可能であるため、サポートされている任意の形式 (組み込みの WCF/SOAP クライアントも含む) で同じ DTO を再利用する機能を提供します。

WS-*/SOAP は不必要に複雑であるため非推奨です。「相互運用可能なサービス」を提供するには、抽象的で明示的であり、複雑さをオプトインする必要があるという誤った前提に基づいて構築されました。その逆です。より単純な形式と単純な URI を使用することで、より少ない労力と摩擦で相互運用性が大幅に向上します。これが、今日の新しい Web API が SOAP をサポートしない理由です。

于 2013-08-14T09:02:11.250 に答える