前言
WCF客户端的ABC中间Address和Binding可以动态配置似乎已经不是什么新鲜事情了，WCF的配置就非常清晰的描述了如何动态配置A和B，但是Contract哪？
Contract包含哪些内容
在一个常规WCF下的Contract有下列部分组成：
- ServiceContract
- OperationContract
- DataContract/MessageContract
如何获得契约
常规的情况下，有下面几种方式获得契约：
- 通过VS中的Add ServiceReference
- 通过SvcUtil.exe创建cs文件
- 直接引用契约的程序集
- 动态根据wsdl生成契约类型
不难发现所有这些方式都需要契约类型。
思考
想想类型为我们带来了什么？
- 优点：把对象和通讯用的Xml隔离
- 缺点：类型不能方便动态配置
如果需要高度动态配置契约的WCF客户端，契约的类型化只会会我们带来不必要的麻烦。
WCF——幻想曲
WCF在传输层本质上传的就是各种形式的Xml（排除那些比较特殊的Binding），当然这个Xml可以是文本编码的常规形式，也可以是Mtom形式，甚至是.net专有的二进制形式。
那么为什么不用Xml本身作为WCF的契约形式？
在这里，我先提出一个XCF的假想概念，用于描述一个基于Xml定义的契约WCF客户端。并且不同于动态生成契约类型，本质上不需要生成任何类型，而仅仅依赖固定的类库和Xml定义。
当然，目前仅仅出于假说阶段，也许基于当前的WCF很难实现，抑或很容易实现，只是没人想到。
后记
为何限定为WCF客户端？
很简单，如果是服务端，在不知道契约的情况下实现契约似乎有点不太可能，或者说，能这样实现的服务端也没多大的意义。
