問題タブ [servicecontract]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
2175 参照

c# - netTcpBinding を使用して WCF サービス参照をクライアント プロジェクトに追加できない

NetTcpBinding を使用する WCF サービスがあり、それを WPF アプリケーションでホストしたいと考えています。サービスは正しく開始されているようですが、ビジュアル スタジオで「サービス参照の追加」を使用してメタデータを取得しようとすると、次の例外が発生します。

私のサービス プロジェクトの App.config ファイル:

ホスティング アプリケーションのコード:

この問題に対して私が見つけた解決策は、主に「serviceMetaData」をサービス構成に追加するか、mex エンドポイントを提供することでした。何か提案していただけますか?

編集:

最終設定:

ホスティング アプリケーション:

0 投票する
1 に答える
307 参照

c# - 1 つのクラスで 2 つのサービス コントラクトを実装する

2 つのサービス コントラクトを実装し、異なるポートで 2 つのエンドポイントを公開するクラスを作成したいと考えています (プログラムへの入力としてポートを取得します)。

私の質問はこの質問とよく似ていますが、それぞれ異なるポートに 2 つのエンドポイントが必要です。

編集:

このコードの使用:

host.Open() 操作で次のエラー メッセージが表示されます。

解決

0 投票する
0 に答える
163 参照

c# - C#ServiceBehaviorカスタムjsonシリアライゼーション

リクエストを逆シリアル化すると、null ではなく空の辞書が取得されます。

投稿したいオブジェクト:

リクエストとともに送信する本文は次のとおりです。

組み込みのシリアライザはData、空の を持つオブジェクトを作成しますDictionary。Newtonsoft シリアライザーは、私の思いどおりに動作します。そのため、グーグルで調べた後、サービス契約をStreamではなく を受け入れるように変更しましたData

ここでの主な問題は、ヘッダーを指定するとリクエストが受け入れられなくなるContent-Type: application/jsonことですData.

サービスのカスタム デシリアライザーを指定するにはどうすればよいですか? または、不可能な場合は、Content-Type が指定されていても現在のソリューションを機能させますか?

0 投票する
4 に答える
413 参照

wcf - WCF サービスでの God オブジェクトのリファクタリング

システムで a に遭遇しgod objectました。このシステムはpublic service、クライアントに公開されている、middle office serviceおよびで構成されていますback office service

フローは次のとおりです。ユーザーがトランザクションを に登録しpublic service、マネージャーmiddle office serviceがトランザクションをチェックしてトランザクションを承認または拒否し、最後にマネージャーがトランザクションをback office service確定または拒否します。

という言葉を使っていますが、実際には、transactionのようなさまざまな種類の操作です ... 操作だけでなく、などの他の多くの操作も...CRUD on entity1CRUD on entiny2CRUDapprove/send/decline entity1make entity1 parent/child of entity2

現在、WCFサービス契約はシステムのこれらの部分に従って分離されています。したがって、3 つのサービス契約があります。

そして、それぞれの膨大な量の操作契約:

これらの運用契約数は、3 つのサービス全体ですでに 2000 であり、各サービス契約あたり約 600 です。ベスト プラクティスを破るだけでなく、サービス リファレンスを更新するだけでも時間がかかるため、非常に苦痛です。また、システムは日々成長しており、反復のたびにこれらのサービスにさらに多くの操作が追加されています。

そして今、私たちはこれらの神のサービスを論理的な部分に分割するにはどうすればよいかというジレンマに直面しています. 1 つのサービスには 12 ~ 20 を超える操作を含めるべきではないと言われています。他の人はいくつかの異なることを言います。黄金律がないことは承知していますが、これについていくつかの推奨事項を聞きたいと思います.

たとえば、これらのサービスをエンティティ タイプごとに分割すると、プロジェクトで約 50 のサービス エンドポイントと 50 のサービス参照を取得できます。この場合の保守性についてはどうでしょうか。

考慮すべきことがもう 1 つあります。これらのサービスをエンティティごとに分割するアプローチを選択するとします。例えば:

ここで、 と の両方でこのサービスへの参照を追加する必要がpublic clientありback office clientます。しかし、操作back officeのみが必要です。これが in の典型的な違反です。そのため、さらに、、 のような 3 つの異なるサービスに分割する必要があります。FinalizeEntity1DeclineEntity1Interface segregation principleSOLIDIEntity1FrontServiceIEntity1MiddleServiceIEntity1BackService