WCF 版本控制:更新属性命名空间并支持以前的命名空间 [英] WCF Versioning : Update Attribute Namespaces and Support Previous Namespaces

问题描述

我有三个 WCF 服务 (.svc)，它们为 SOAP 消息生成 .wsdl 引用.

I have three WCF services (.svc) which generate .wsdl references for SOAP messages.

假设命名空间的一部分需要针对所有 ServiceContract、OperationContract、DataContract 属性进行更改，例如

Given that part of the namespace needs to change for all ServiceContract, OperationContract, DataContract attributes, for example

[DataContract(Namespace = "http://old.com.au/types/")]

到

[DataContract(Namespace = "http://new.com.au/types/")]

为什么我仍然可以支持具有旧服务引用的客户端(无需他们更新，因为他们可能没有时间立即更新)并允许客户端获得新的服务引用以获取新的服务引用命名空间? 没有任何服务在改变，只有命名空间.

到目前为止，我已经阅读了很多内容，但以下文章表明可以从 ServiceHostFactory 更改服务类型:http://blog.ranamauro.com/2008/07/hosting-wcf-service-on-iis-site-with_25.html

So far I have read a lot of stuff but the following article suggests it is possible to change the service type from the ServiceHostFactory : http://blog.ranamauro.com/2008/07/hosting-wcf-service-on-iis-site-with_25.html

这意味着为每个合约创建两个(将尽可能多的实现放在一个地方)，并在运行时确定要使用的服务类型.这会在我的场景中造成一些混乱.

Which would mean creating two of every contract (putting as much of the implementation as possible in one place), and figuring out at runtime which serivce type to use. This would create some mess in my scenario.

问.是否有替代的、不错的方法来实现这一点，或者是否期望这种事情不应该做并且客户端更新到新的命名空间.

(如果来自客户端的命名空间不匹配，我会收到错误消息:由于 ContractFilter 不匹配，无法在接收方处理带有操作..."的消息)

(If there is a namespace mismatch from the client I get the error : The message with Action "..." cannot be processed at the receiver, due to a ContractFilter mismatch)

推荐答案

IMO，您需要在(最好)旧端点为以前的客户托管旧服务，并在新端点拥有新服务.当所有旧客户端迁移到新版本时，您可以取消旧服务.或许，您可以使用继承来减少您的工作量，例如

IMO, you need to host old services for your previous clients at (preferably) old end points and have new services at new end points. You can take out old services when all your old clients migrate to newer version. Perhaps, you can use inheritance to reduce your efforts, for example

[DataContract(OldNameSpace)]
ClassA {
 ...
}

[DataContract(NewNameSpace)]
ClassB : ClassA {
}

同样，从新的服务契约继承来创建新的服务契约.服务实现不需要改变，除非它需要实现新的契约.现在您必须配置两个端点 - 一个用于旧合同，另一个用于新合同.

Similarly, create new service contract from inheriting from new one. Service implementation need not change expect it needs to implement new contract. Now you have to configure two end point - one for old contract and another for new contract.

放置示例接口和实现

假设您的旧合同类似于

public interface IOldContract
{
    ClassA GetFoo();
    void DoBar(ClassA a);
}

现在您可以选择新合同作为

Now you can choose the new contract either as

public interface INewContract
{
    ClassB GetFoo();
    void DoBar(ClassB b);
    ClassB GetMix(ClassB a);
}

或作为

public interface INewContract2 : IOldContract
{
    ClassB GetFoo2();
    void DoBar2(ClassB b);
    ClassB GetMix2(ClassB b);
}

我倾向于采用后来的变化(因为新合同与旧合同保持兼容).但是在您的情况下，您可以选择前者，因为无论如何您都会暴露两个端点.现在你需要修改服务实现如下:

I tend to go with later variation (as new contract remains compatible with old one). But in your case, you can choose former as you will be anyway exposing two endpoints. Now you need modify service implementation as follows:

    public class ServiceImplementation : INewContract2
{
    #region INewContract2 Members

    public ClassB GetFoo2()
    {
        // Your old implementation goes here 
    }

    public void DoBar2(ClassB b)
    {
        DoBar(b);
    }

    public ClassB GetMix2(ClassB b)
    {
        return GetMixHelper(b);
    }

    #endregion

    #region IOldContract Members

    public ClassA GetFoo()
    {
        return GetFoo2();
    }

    public void DoBar(ClassA a)
    {
        // You old implementation goes here
    }


    public ClassA GetMix(ClassA a)
    {
        return GetMixHelper(a);
    }

    #endregion

    private ClassB GetMixHelper(ClassA a)
    {
        // Your old implementation goes here
    }

}

我希望你能明白.即使在这里，您也有多种代码组织选择.您可以有两个骨架服务实现类 - 一个用于旧合同，另一个用于新合同.两者都会将实际功能委托给一个辅助类(这是您当前的实现).

I hope that you get the idea. Even here also you have multiple choices of code organization. You can have two skeleton service implementation classes - one for old contract and another for new contract. Both will delegate actually functionality to a helper class (which is your current implementation).

这篇关于WCF 版本控制:更新属性命名空间并支持以前的命名空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！