そのトピックについては多くの議論があったことは承知していますが、エンタープライズSOAの環境にとって何が良いのか混乱しています。基本的には、かなり動的に変化する、いくつかのWCF WebサービスといくつかのデスクトップWPFアプリケーションを備えたSOAシステムです。
オプション1:
mex
エンドポイントを使用して各サービスをデプロイします。自動生成/検出されたクライアントを使用して、各クライアントにプロキシを実装します。サービスが変更されるたびに、クライアントアプリを開き、サービス参照を更新してデプロイします。
オプション2:
各サービス(サービスのリポジトリー内)にProxy
プロジェクトを実装します。手動で実装されたクライアントはChannelFactory
を使用します。次に、このProxy
を会社のナゲットにプッシュします。次に、このサービスをWPFアプリで使用するたびに、nugetパッケージをプルします。 WCFサービスが変更されたら、Proxyライブラリを更新し、nugetにプッシュします。そして、WPFアプリから更新します。
だから基本的に、nuget対svcutil?
私はオプション2と言うでしょう。
一種のジェネリックラッパーを作成し、カスタマイズされた実装と例外処理戦略を1か所にまとめ、nugetとして公開すると、どのクライアントでも簡単に利用できます。
*たとえば、私が現在使用しているものは、WCFサービスを公開しているアプリケーションサーバーから受信したさまざまなFaultException<T>
に応じて、Webサーバーで適切なhttpステータスコードに変換することも行います。
これが通常の方法です:サービスとクライアントは偶然同じソリューションの一部です(もちろん、展開モデルはサービスベースのcsprojとクライアントアプリケーションでは異なります)。 WCFクライアントは、コアライブラリの一部として公開され、クライアントアプリケーションによって参照されます。サービスとクライアントアプリケーションは同じソリューションの一部であるため、データコントラクト関連の.csファイルをリンクファイルとして参照できます。また、これはエンタープライズアプリケーションのかなり標準的なパターンであり、私自身の発明ではありません:)