クライアントに影響するWCF契約の変更
-
08-07-2019 - |
質問
誰かが、サーバー側でどの種類のWCFコントラクト(インターフェイス)の変更を行うと、クライアントがメッセージを送信しようとしても壊れるのか、その理由を説明できたらと思っていました。 WCFは特定の不一致を処理できると信じていますが、安全に変更できるものとできないものは正確にはわかりません。
- OperationContractにパラメーターを追加/削除しますか?
- DataContractのシリアル化されたプロパティを追加/削除/変更しますか?
- OperationContractsをServiceContractに追加/削除しますか
ここで友人が同様の質問をしました:
メソッドをWCFに追加しますServiceContractは既存のクライアントを破壊しますか?
編集:ジョン・サンダースが指摘したように、契約を変更することは通常良いアイデアではありませんが、何らかのバージョンの許容範囲を可能にするものが組み込まれています(ExtensionDataObjectなど?)。バージョンの許容範囲がどれほど柔軟かを知りたいだけです。
解決
dasBlondeのこの記事をご覧ください: WCFサービスコントラクトのバージョン管理
既存のクライアントに影響を与える変更のリスト:
- 操作を削除
- 操作名の変更
- 操作パラメーターの削除
- 操作パラメーターの追加
- 操作パラメーター名またはデータ型を変更する
- 操作の戻り値の型を変更する
- .NET属性またはカスタムシリアル化コードを明示的に使用して、パラメータータイプ(データコントラクト)または操作(メッセージコントラクト)のシリアル化されたXML形式を変更する
- サービス操作のエンコード形式の変更(RPCエンコードとドキュメントリテラル)
Micheleによるこの記事で詳しく説明しています契約をより柔軟に設計する方法の詳細。
他のヒント
契約に関する設計上の推奨事項
-
最初のバージョン
1.1。すべてのコントラクト(インターフェイス、メソッド、クラス、およびプロパティ)の名前を慎重に選択してください。これらは将来のバージョンで変更するのが難しいでしょう。
1.2。将来的には、次のものは変更できないことに注意してください:メソッドパラメーターの数、パラメーターの型/戻り値/制御下にない型のプロパティ。
-
次のバージョン
2.1。既に存在する場合、xxxContractAttributeのNamespaceまたはNameパラメーターを変更しないでください。
2.2。既に存在する場合、DataMemberAttributeのOrderプロパティを変更しないでください。
2.3。次の変更のみが許可されています:
-
インターフェース(ServiceContract)へのメソッド(OperationContract)の追加
-
インターフェイスの名前変更メソッド
-
クラス名の変更(DataContract)
-
クラス(DataContract)にプロパティ(DataMember)を追加
-
クラスのプロパティの名前を変更
2.4。削除すると互換性が失われます。
2.5。他の変更は互換性を壊します。
-
役立つリンクをいくつか次に示します。
" OperationContractにパラメーターを追加/削除します" WCFでは、常にクライアントを破壊する可能性があるものではありませんが、何をすべきかを知っておく必要があります。 特に、操作コントラクトに新しいパラメーターを追加すると、レガシークライアントはそれらを渡さなくなり、サービス側ではデフォルト値で設定されます。 さらに、オペレーションコントラクトからパラメータを削除すると、クライアントの観点からは静かになり、サービス側では単純に無視されます。 もちろん、パラメータの名前/タイプを変更すると、クライアントが破損します。
ベストプラクティスは、契約を解読不能な、うーん、契約 と考えることだと思います。それらが公開されたら、それらを変更しないでください。必要な変更で新しいコントラクトを作成し、新しいエンドポイントで新しいコントラクトを公開するのは簡単です。
OK。質問。命名構文が間違っているため(パラメーターは大文字で指定されています)、いくつかのコードを調整します:
[OperationContract]
public void Foo(string Bar){}
to
[OperationContract]
public void Foo(string bar){}
キャピタルブレイク契約を調整しますか?