|
|
客户端调用WCF服务的方式不外乎有两种：其一、通过代码生成工具（比如SvcUtil.exe）导入服务的元数据生成服务代理相关的类型；其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者，生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象，其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说，ChannelFactory<TChannel>是一个核心类型。
目录
一、创建ChannelFactory<TChannel>
二、客户端架构体系
信道初始化
消息检验
操作和操作选择
三、 客户端操作（ClientOperation）
一、创建ChannelFactory<TChannel>
服务调用的本质实际上是针对服务的某个终结点的调用，说得具体地应该是：客户端通过相匹配的终结点调用服务的终结点。终结点具有ABC(Address, Binding, Contract)三要素，这里所说的“相匹配”的终结点具体体现在这三要素的匹配上。而服务调用最终体现在消息交换上，接下来我们从消息交换的角度来谈谈匹配终结点在服务调用的必要性。
- 地址（Address）：地址作为调用服务的唯一标识并代表了服务所在的位置，客户端终结点必须具有一个正确的地址才能确保请求的消息被发送到正确的目的地；
- 绑定（Binding）：作为信道层的缔造者，绑定最终创建了用于实现消息处理和传输的信道栈。客户端必须具有一个与服务端一致的信道栈，才能确保消息的一致性处理。具体来说，客户端必须具有与服务端一致的传输信道，才能确保消息能够被正常地传输到服务端。如果服务端具有采用一个基于HTTP协议的传输信道进行请求的监听，客户端就不能使用一个基于TCP的传输信道。服务端和客户端必须具有一个相同的消息编码信道才能确保被一方编码的消息能够被另一个解码。如果服务端采用基于文本的消息编码信道，客户端采用的消息编码信道就不能是基于二进制的。此外，几乎所有的WS-*规范在WCF的实现都是通过自定义信道来控制消息交换来完成的，所以这也要求客户端和服务端必须具有对等的信道设置；
- 契约（Contract）：契约最终决定了基于某个操作的服务调用应该采用的消息交换模式，以及参与消息交换的消息本身所具有的结构。为了让客户端和服务端就此达成一致，必要要求双方采用等效的契约。
用于创建服务代理对象的ChannelFactory<TChannel>对象本身就是基于某个具体的客户端终结点创建的。你可以通过编程的方式（构造函数）指定终结点的三要素，也可以将此三要素定义在配置文件中，通过终结点配置名称（构造函数的endpointConfigurationName参数）来创建ChannelFactory<TChannel>。下面的代码片断给出了相关定义。
public abstract class ChannelFactory : CommunicationObject, IChannelFactory, ICommunicationObject, IDisposable{
public ServiceEndpoint Endpoint { get; }
}
public class ChannelFactory<TChannel> : ChannelFactory, IChannelFactory<TChannel>, IChannelFactory, ICommunicationObject
{
//其他成员
public ChannelFactory(string endpointConfigurationName);
protected ChannelFactory(Type channelType);
public ChannelFactory(Binding binding, EndpointAddress remoteAddress);
public ChannelFactory(Binding binding, string remoteAddress);
public ChannelFactory(string endpointConfigurationName, EndpointAddress remoteAddress);
}
NET技术：WCF客户端运行时架构体系详解[上篇]，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
