WCF从理论到实践

    仔细观察代理的代码不难发现，代理中的服务契约以及服务实现的操作与服务端定义的想比，有所更改。而且对于代理类来说，已经没有了重载，虽然此代理类能够被正常使用，但是却没有了重载的好处，如何更改代理类，才能使其也有重载是下面要研究的问题。

    我们将代理中的服务契约IService中的操作定义修改为：

    [System.ServiceModel.OperationContractAttribute（Action="http://tempuri.org/IService/AddInt"， ReplyAction="http://tempuri.org/IService/AddIntResponse"，Name="AddInt"）]

    int Add（int a， int b）；

    [System.ServiceModel.OperationContractAttribute（Action="http://tempuri.org/IService/AddDouble"， ReplyAction="http://tempuri.org/IService/AddDoubleResponse"，Name="AddDouble"）]

    double Add（double a， double b）；

    然后将服务实现ServiceClient中的方法更改为：

    public int Add（int a， int b）

    {

    return base.Channel.Add（a， b）；

    }

    public double Add（double a， double b）

    {

    return base.Channel.Add（a， b）；

    }创建一个Console的客户端应用程序，然后将修改后的Proxy.cs拷贝到其中，实现客户端调用，代码如下：

    IService ws = new ServiceClient（new NetTcpBinding（）， new EndpointAddress（"net.tcp://127.0.0.1：12345"））；

    using （ws as IDisposable）

    {

    Console.WriteLine（ws.Add（1，2）。ToString（））；

    Console.WriteLine（ws.Add（1.3， 2.4）。ToString（））；

    }

    Console.Read（）；将解决方案设置为多启动项目，并启动托管和客户端，出现下面的结果：

    说明客户端和服务端已经成功通讯。从上面实现客户端的方法来看，客户端想实现重载，也必须保证重载操作的别名要有服务端的相匹配，其各不相同。

    小结

    从本文可以看出，WCF编程虽然保持了大部分原有编程模式，也继承了原有模式足够多好的做法，但是限于分布式开发与传统应用程序的差异，在有些细节上还是有区别的，比如本文所讨论的操作重载问题，其实还有很多类似问题，比如继承的差异，序列化的差异，处理集合的差异等等。要想真正的掌握这些问题，必须要深刻了解分布式开发的特型。加深对服务交互，类型转换，封送等WCF架构方面的理解。以下几点是对本文的总结：

    1） 对于WCF中的服务端，对服务契约和服务实现不支持显示的操作重载，但可以通过设置重载操作的别名来改善这种状况2） 对于WCF客户端，默认情况下，生成的代理也不支持操作重载，想要改变这种状况也必须依赖于别名。

    3） 我推荐的做法是在服务端还是要用别名的方式支持操作重载，在客户端手动更改代理类，以便也支持操作重载。

上一页  [1] [2] [3] [4] 

【责编:Ken】