wcf已经说到第六天了,居然还没有说到这玩意有几种通信模式,惭愧惭愧,不过很简单啦,单向,请求-响应,双工模式,其中的第二种“请求-响应“
模式,这个大家不用动脑子都清楚,这一篇我大概来分析下。
## 一:“请求-响应“模式
如果你看了我上一篇的博文,你应该非常清楚这种类似“本地调用”的方式,wcf同样也分为“同步”和“异步”两种,不过不管是异步还是同步,最终都逃
不过是“请求-响应”这个事实,对吧。
1: 同步方式
这种方式我想没什么好说的,前面几篇我已经说的非常清楚了,具体使用方法可以参考我的前面几篇文章。。。谢啦~~~~
2: 异步方式
通常我们都有这样的一个思维,遇到耗时的东西第一反应就想到了多线程,毕竟多线程也是一种负载均衡,在wcf这种”请求-响应“模式,同样也支持异
步,很神奇吧,而且神奇到可以在“服务引用“界面上做到一键生成,什么???你不信!!!!不信你看。。。
![](https://box.kancloud.cn/2015-08-04_55c0b3ce7bd13.png)
然后我非常好奇的看下XXXClient给我们生成的是个什么代码。。。
![](https://box.kancloud.cn/2015-08-04_55c0b3cf33723.png)
通过client端的proxy代码,你可以清楚的看到,这鸡巴WCF真的不容易,给我们生成了两种“异步模式”,第一种是最古老的beginXXX,endXXX模式,
还有一种是被Jeffrey Richter 严重鄙视的“事件异步模式”。。。没什么好说的,截图一下给大家看看。
![](https://box.kancloud.cn/2015-08-04_55c0b3cfaafe9.png)
## 二:“单向“模式
很多时候,我们或许都有这样的需求,比如说订单提交成功的时候,我需要给客户发送邮件,但是你想想,我发送邮件这个任务只是我订单流程的
一个“额外任务“,也就是说,它的失败不应该会阻止我的订单流程,并且它的逻辑时间不应该会阻碍我的下单总时间,对吧。。。这样的话,我的订单时
间才会最小化,为了达到不影响下单总时间的效果,我的想法就是,client端直接把消息丢给信道就好了,然后不管server端有没有真的接收到,处理的
慢不慢,过的好不好,等等,非常开心的是,这些对wcf来说真的是小菜一碟,只需要一个轻轻松松的”IsOneWay=true“属性就可以了。。。牛逼的要
死。。。还有就是因为是单向的,所以契约方法就没有存在返回值的必要了,我说的对吧。。。嘿嘿~~~
~~~
[ServiceContract]
public interface IHomeService
{
[OperationContract(IsOneWay = true)]
void Update(Student message);
}
~~~
~~~
namespace MyService
{
public class HomeService : IHomeService
{
public void Update(Student message)
{
Console.WriteLine(message.Name);
}
}
[DataContract]
public class Student
{
[DataMember]
public string Name { get; set; }
[DataMember]
public int Age { get; set; }
}
}
~~~
为了验证是否真的是单向通讯,我可以用二种方法验证下。
1\. wsdl中是否有output这个message
通过下面的图,我想你看的很清楚了,你再也没有找到我们熟悉的“output”这个message,这就说明貌似真的是单向的了,因为wsdl就是web服务的清单。
![](https://box.kancloud.cn/2015-08-04_55c0b3d02f23b.png)
2\. 使用fillder监视一下请求消息
~~~
class Program
{
static void Main(string[] args)
{
HomeServiceClient client = new HomeServiceClient();
client.Update(new Student() { Name = "hxc" });
}
}
~~~
![](https://box.kancloud.cn/2015-08-04_55c0b3d10aef7.png)
正如我在图中说的那样,非常奇怪,我的IsOneWay模式,竟然在http模式下行不通,但是你要记住,http模式天生就是“请求-响应”模式,它完全做不了
单向模式,说明白一点就是:“wcf发现你的bingding不支持单向“的时候,它并不会报错,还是用自己天生的”请求-相应“模式来模拟”单向通信“,这就是你
看到的非常奇怪的Http 202这个http状态码,很多人包括我,都不知道http202 是几个意思,没关系,我们百科一下就好了。。。下面框框的里面的字,
已经说的非常清楚了,感谢感谢。。。
![](https://box.kancloud.cn/2015-08-04_55c0b3d1ac0e6.png)
## 三:“双向“ 模式
这个通讯其实没什么好讲的,也只有tcp模式才会天生支持,而http模式天生就不支持,就像上面一样,如果非要用http来支持“双向通讯“,那又是在
坑"wcf"他爹,这样就会逼着他爹在底层再建立一个“请求-响应“模式来支持所谓的”双向通讯“,而且”双向通讯“这个玩意还不如用两个单向的”请求-响应”模
式或者两个“单向模式”来支持,而且两个”请求-响应“模式比”双向通讯“有更大的灵活性,反正我是对它不感冒,了解一下即可,如果大家比较感兴趣,可以
在wcf官网上看一下:https://msdn.microsoft.com/zh-cn/library/ms735119.aspx。
好了,就说到这里,洗洗睡了,晚安~~~~
- 第一天 三种Binding让你KO80%的业务
- 第二天 告别烦恼的config配置
- 第三天 client如何知道server提供的功能清单
- 第四天 你一定要明白的通信单元Message
- 第五天 你需要了解的三个小技巧
- 第六天 你必须要了解的3种通信模式
- 第七天 Close和Abort到底该怎么用才对得起观众
- 第八天 对“绑定”的最后一点理解
- 第九天 高级玩法之自定义Behavior
- 第十天 学会用SvcConfigEditor来简化配置
- 第十一天 如何对wcf进行全程监控
- 第十二天 说说wcf中的那几种序列化
- 第十三天 用WCF来玩Rest
- 第十四天 一起聊聊FaultException
- 终结篇 那些你需要注意的坑