考慮する必要があることがいくつかあります。まず、コントラクトとスキーマ/メッセージに名前空間を追加する必要があります。なんで?バージョン1と2の操作とメッセージが類似している場合、それらは互いに競合する可能性があるためです。名前空間を追加すると、コード/クライアントは2つの異なる実装を処理していることがわかります。
次に、サービスの契約を変更する理由を尋ねたい場合があります。要件操作を追加する必要があるからですか。それとも、新しいWCFサービスに分離できるまったく新しい機能ですか。バージョンを維持したい場合は、まったく新しい機能を新しいサービスに入れ、それが現在のサービスの一部である必要がある場合は、コントラクトをコピーして別のバージョンを作成します。
サービスのコントラクトを変更すると、そのコントラクトを現在使用しているクライアントが破損します。サービス用に別のバージョンを作成すると、現在のクライアントは、そのクライアントを更新するまで以前のバージョンで作業を続けることができます。だからあなたはこのようなものを手に入れるでしょう。
namespace MyNamespace.Contracts.V1
{
[ServiceContract(Namespace = "urn:company:project:servicename:v1")]
public interface IService
{
[OperationContract]
void RequirementA();
}
}
namespace MyNamespace.Contracts.V2
{
[ServiceContract(Namespace = "urn:company:project:servicename:v2")]
public interface IService
{
[OperationContract]
void RequirementA();
[OperationContract]
void RequirementB();
}
}
両方のバージョンは別々にホストされ、実装も異なります。ただし、実装に操作をある種の(ビジネス)コントローラーに委任させることができます。これは両方のバージョンをサポートし、フローは次のようになります。
- V1.IService-V1.Implementationは、呼び出しをMyServiceControllerに委任します
- V2.IService-V2.Implementationは、MyServiceControllerへの呼び出しも委任します
このようにして、実行する必要のある(ビジネス)ロジックを1つのコントローラーで処理し、重複する可能性のあるコードを防ぐことができます。