十五天精通WCF——第十二天 说说wcf中的那几种序列化

  

  我们都知道wcf是由信道栈组成的,在我们传输的参数走到传输信道层之前,先需要经过序列化的过程,也就是将参数序列化为message,这篇

我们就来说说这里的序列化,蛮有意思的,可能初学者也明白,在wcf中默认的序列化是DataContractSerializer,确实是这样,不过wcf在信道中

其实不仅仅支持DataContractSerializer,它还支持其他类型的序列化,比如XmlSerializer,NetDataContractSerializer以及DataContractJson

Serializer,下面我们一起来见证下。

1. XmlSerializer

要了解XmlSerializer,我们先来简单看看NetDataContractSerializer,在前面的文章中,我也说过DataContract就是将我们的model序列化为

XSD,第二点就是使用DataContract的原则就是你必须在Model上加DataContract,而且在你要序列化的字段上加DataMember。这样才能够正确的序列

化,为了演示,我们先看看默认的序列化Model会变成啥样?

 1     [DataContract]
 2     public class Student
 3     {
 4         [DataMember]
 5         public int ID { get; set; }
 6
 7         [DataMember]
 8         public string Name { get; set; }
 9
10         [DataMember]
11         public string SNS { get; set; }
12     }

但是在有些情况下,你可能并不适合用DataContract,比如Model是第三方提供的,那么这个时候你的Model可能就不会有DataContract标记,那这样的

话wcf就无法进行序列化,那我如果非要保证wcf能正常跑起来的话,还有其他好的办法吗???当然了,肯定有办法,这就好比谈恋爱一样,总不能

在一棵树上吊死吧,没人谁离不开谁,也不会谁离开了谁会死,天涯何处无芳草,男儿何患无妻,对吧。Wcf中也一样,既然DataContract用不了,自

然会有替代它的人,那这个人就是XmlSerializer,使用起来也很简单,就是在契约方法上面加上XmlSerializerFormat即可,然后我们把Model的

DataContract全部去掉。

是不是很简单,下面我们就要验证一下,看看这个Format是否进入到了这个Operation的Behavior中,

从上面的图中,你也看到了, XmlSerializerFormat 已经被注入到Behavior中,并且是由类XmlSerializerOperationBehavior代为处理。

接下来,我们用fiddler监视一下,看看Message中的Body是否真的按照XmlSerializer 序列化了。

有没有看到,这次Message的Body已经和文章开头处的Message不一样了。

2. NetDataContract

这个玩意也没什么好说的,光从表面上看,它和DataContract唯一不同的地方就是多了一个Net,所以你大概也能猜到,这个功能大概和DataCont

ract一样,只不过比DataContract多了一个程序集保存,那这句话是什么意思呢???就是NetDataContract会把程序集的命名空间和类名都保存到XSD中,

在反序列化的过程中必须要用同样的程序集才能解开,其实不管我们是做SOA或者面向对象编程都讲究接口编程,而NetDataContract给你的印象就是面

向对象编程,当然这也有好处,比如说如果把程序集带进去就好像秘钥一样,必须有它才能解开,对吧,所以导致wcf项目组并不对NetDataContract感冒

,所以在实际应用上也不建议使用。

3. DataContractJsonSerializer

看到上面这个带有Json的字样,我想大家都知道这玩意是干什么的???没错,他就是将我们的Model序列化成Json,这在wcf的rest编码使用的很广,

如果大家有兴趣的话,我在下一篇会详细描述,这里我们先简单看一看。

好了,这一篇就说这些了,洗洗睡了。。。

时间: 2024-08-02 02:41:56

十五天精通WCF——第十二天 说说wcf中的那几种序列化的相关文章

十五天精通WCF——第四天 你一定要明白的通信单元Message

原文:十五天精通WCF--第四天 你一定要明白的通信单元Message 转眼你已经学了三天的wcf了,是不是很好奇wcf在传输层上面到底传递的是个什么鸟毛东西呢???应该有人知道是soap,那soap这叼毛长得是什么 样呢?这一篇我们来揭开答案... 一:soap到底长成什么样子 为了能看清soap长的啥样,我可以用强大的Fiddler来监视一下,突然好激动啊!!! 1.Server 1 static void Main(string[] args) 2 { 3 ServiceHost host

十五天精通WCF——第一天 三种Binding让你KO80%的业务

原文:十五天精通WCF--第一天 三种Binding让你KO80%的业务 转眼wcf技术已经出现很多年了,也在.net界混的风生水起,同时.net也是一个高度封装的框架,作为在wcf食物链最顶端的我们所能做的任务已经简单的不能再简单了, 再简单的话马路上的大妈也能写wcf了,好了,wcf最基本的概念我们放在后面慢慢分析,下面我们来看看神奇的3个binding如何KO我们实际场景中的80%的业务场景. 一:basicHttpBinding 作为入门第一篇,也就不深入谈谈basic中的信道栈中那些啥

十五天精通WCF——第九天 高级玩法之自定义Behavior

原文:十五天精通WCF--第九天 高级玩法之自定义Behavior 终于我又看完了二期爱情保卫战,太酸爽了,推荐链接:http://www.iqiyi.com/a_19rrgublqh.html?vfm=2008_aldbd,不多说,谁看谁入迷,下面言归正传, 看看这个很有意思的Behavior. 一: Behavior这个泼妇的厉害   在前面的文章中,我也清楚的说明了整个wcf通信流,而Behavior这个泼妇可以在wcf通信流中的任何地方插上一脚,蛮狠无比,利用的好,让你上天堂,利用的不

x264代码剖析(十五):核心算法之宏块编码中的变换编码

x264代码剖析(十五):核心算法之宏块编码中的变换编码 为了进一步节省图像的传输码率,需要对图像进行压缩,通常采用变换编码及量化来消除图像中的相关性以减少图像编码的动态范围.本文主要介绍变换编码的相关内容,并给出x264中变换编码的代码分析. 1.变换编码 变换编码将图像时域信号变换成频域信号,在频域中图像信号能量大部分集中在低频区域,相对时域信号,码率有较大的下降. H.264对图像或预测残差采用4×4整数离散余弦变换技术,避免了以往标准中使用的通用8×8离散余弦变换逆变换经常出现的失配问题

十五天精通WCF——第十一天 如何对wcf进行全程监控

说点题外话,我们在玩asp.net的时候,都知道有一个叼毛玩意叫做“生命周期”,我们可以用httpmodule在先于页面的page_load中 做一些拦截,这样做的好处有很多,比如记录日志,参数过滤,全局登录验证等等...在wcf里面的话也是有类似的功能,第一种就是在 endpoint中加上runtime的behavior,这样的话就可以先于“服务方法”做拦截,第二种方法呢,也就是我们这一篇所说的全程监控,俗称 ”诊断功能”. 一:诊断 我也说了,“诊断”这是wcf的一个专业术语,意思也就是监控

十五天精通WCF——第十四天 一起聊聊FaultException

 我们在玩web编程的时候,可能你会不经意的见到一些http500的错误,我想你应该不会陌生的,原因你应该也知道,服务器异常嘛, 这时候clr会把这个未处理的异常抛给iis并且包装成http500的错误返回到客户端,就比如下面这样. 从这张图中,我故意输入了xss字符,然后的然后,web程序自爆异常,其实我想表达的意思就是,虽然说web程序抛异常了,但不代表iis就 挂了,所以iis还是需要给客户端做出反馈,这就有了http header,和body信息,同样的道理,wcf的服务器异常机制也是这

十五天精通WCF——第六天 你必须要了解的3种通信模式

wcf已经说到第六天了,居然还没有说到这玩意有几种通信模式,惭愧惭愧,不过很简单啦,单向,请求-响应,双工模式,其中的第二种“请求-响应“ 模式,这个大家不用动脑子都清楚,这一篇我大概来分析下. 一:“请求-响应“模式   如果你看了我上一篇的博文,你应该非常清楚这种类似“本地调用”的方式,wcf同样也分为“同步”和“异步”两种,不过不管是异步还是同步,最终都逃 不过是“请求-响应”这个事实,对吧. 1: 同步方式 这种方式我想没什么好说的,前面几篇我已经说的非常清楚了,具体使用方法可以参考我的

十五天精通WCF——第十天 学会用SvcConfigEditor来简化配置

我们在玩wcf项目的时候,都是自己手工编写system.serviceModel下面的配置,虽然在webconfig中做wcf的服务配置的时候,vs提供大多 数的代码提示,但对于不太熟悉服务配置的小鸟们来说,有些困难,而且一些服务配置也容易遗漏,大多情况下,我们都是copy一份服务配置,然 后在服务配置上面修修改改,对吧...其实呢,.net给我们提供了一个强大的scvconfigeditor这个工具化的软件来帮助我们生成wcf的配置,是 不是很神奇??? 一:工具在何处 当然在无比牛逼的Mic

十五天精通WCF——第二天 告别烦恼的config配置

经常搞wcf的基友们肯定会知道,当你的应用程序有很多的“服务引用”的时候,是不是有一种疯狂的感觉...从一个环境迁移到另外一个环境,你需要改变的 endpoint会超级tmd的多,简直就是搞死了人...好了,这篇我们来看看如何最小化配置. 一:精简service的config配置 就像上一篇的代码一样,我的service端的config配置如下: 1 <?xml version="1.0" encoding="utf-8" ?> 2 <config