WCF学习过程和心得（一）

2017/9/20 第一天 一个简单的例子 CalculatorService

1、理解得还很浅，先把WCF当作一个WebService的框架。我使用HttpListner创建过服务器端，接收客户端请求，可以把WCF当作一个替代吧，不需要写Http的监听，也不需要根据请求内容写分发。

2、C#创建WCF的解决方案，有三个项目：

1）Server（包括Contacts和Services，就是服务器了），这是个类库。

2）Hosting，一个命令行的应用程序，用来承载Server。

3）Client，客户端程序。可以是命令行，可以是图形界面。

WCF服务可以承载在ASP server上，但是这个我现在不用，先不学他。

C#有个WCF应用程序的功能类型，这个是自动创建ASP server来承载服务的，所以我不用。

《WCF技术剖析（卷一）》中，把Server拆成了Contacts和Services两个项目，我没这么做，因为反正都是我一个人写，我创建了个Server工程，包含Contacts和Services这两个命名空间。

3、Contacts中，使用Interface来定义契约（好吧，跟着书上来，可能是业界的标准叫法，按我的习惯我会叫协议）。跟Spring的注解注入相似，需要在Interface上通过[ServiceContact]来标记这是一个契约，方法也要标记[OperationContact]。

标记ServerContact时可以指定Namespace，我理解就是服务的IP:Port，还有个Name就是服务名。在代码里面写死这个肯定不利于服务的部署。应该肯定有配置形式的。

4、Services中，用Service类来实现契约Interface，没有什么好说的。

5、Hosting承载服务，就是创建服务，并增加Endpoint，这个Endpoint由Address、Binding、Contact组成。我理解，Address就是提供服务的地址；Binding是指交付的格式，比如WSHttp；Contact就是契约了。告诉框架这些信息，WCF框架会从Address接收请求，并用Binding的格式来解析请求内容，与Contact匹配，并交给实现了Contact接口的类来处理。那么我有进一步的推测：

1）在Contacts定义中的Namespace和Name，对于部署业务没有什么作用。

2）一个Contacts的Interface不能有多个实现类。

这两个推测待后续求证。

Hosting还可以通过MetaData来提供契约的说明，这个是非常有用的。

承载服务有代码形式和配置形式，同样的，为了方便部署，应该采用配置形式。

因为现在看得例子中，服务器只定义了一个Contact，一个Service，Hosting是加了一个服务，一个Endpoint，所以我现在还不明白Hosting承载多个服务时，如何去做。我猜测哈，增加多个服务肯定要的。SOA嘛，允许增加服务，不可能事先都加好。

6、Client。客户端也是属于WCF框架内的，也要引用System.ServiceModel模块，客户端与服务器之间的通信被完全封装了。（我想，如果客户端不引用System.ServiceModel也可以，自己实现与服务器之间的通信和消息封装）。

封装的意思是，网路消息格式和请求参数的组装都不需要我管，在客户端这一侧，复制了一Contact，可以像调用本地方法一样向服务器发出请求。

客户端最关键就是为要使用的契约创建本地的“副本”，方法有两个：

1）通过获取服务的MetaData（在服务已经运行的条件下，引用服务），自动生成“副本”，客户端直接创建这个”副本“的对象，调用这个对象内定义的方法即可。所以说MetaData非常有用。微软的代码自动生成技术那也是相当的牛逼。

2）如果Server和Client本来就在一个解决方案里面（比如我的情况），那就不需要通过MetaData了，直接引用Server定义的Contact类就可以了。在客户端也创建一个Endpoint，使用ChannelFactory来创建一条客户端和服务器两个Endpoint之间的通道。然后一样的，在本地调用Channel中的方法来请求服务。