|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
效率会有不少的变化。而实际上net网页编程是基于堆栈机器来设计,这和我们常见的基于寄存器的本地机器是差异比较大的。总体来说,这是一种虚拟机的设计思路。.NET供应了良多序列化对象的办法,懂得他们之间的区分才干更好地断定利用哪种序列化体例并准确地利用。本文从上面几个方面临题目中的三种序列化办法举行了剖析。
- 局限:PropertyOrFieldOrBoth
- 可见性:PublicorPrivateOrAll
- 可会见性:ReadonlyProperty
- 回调:指OnSerializing,OnSerialized,OnDeserializing,OnDeserialized这些回调。
- 包括轮回援用的对象
- 包括Dictionary的对象
- 乱序读(XML)
- 自界说序列化了局。
- 对被序列化的类有无甚么Attribute请求。偶然被序列化的对象位于第三方库中,没法修正源代码,假如要序列化如许的对象,就不克不及利用必定要有Attribute的Serializer。
先把了局收拾出来再剖析:代码能够从这里下载,所写测试大概其实不周全,以是假如有甚么毛病,接待人人指出,否则要误人后辈了。不外有这篇更误人后辈的文章殿底(Googletop1),我信任这个表不会更糟。
XmlSerializerDataContractSerializerBinaryFormatter局限BothBothFieldOnly可见性PublicOnlyAllAll只读属性不撑持撑持,但要加AttributeN/A回调撑持不撑持撑持撑持轮回援用不撑持撑持,但要加Attribute撑持Dictionary不撑持撑持,专有格局撑持乱序读撑持不撑持不撑持自界说格局撑持,要加Attribute不撑持XmlAttribute经由过程接口Attribute请求不用要不用要必需有Serializable
有几点必要注释一下。
功能?巨细?
在我写的几个测试用例中,不管关于复杂对象,仍是嵌套对象,仍是数组反复援用对象,这几个Serializer的功能和巨细基础在一个数目级上。他们之间功效上的差别宏大于他们功能上的差别。这个时分,利用哪一个办法的决议应当取决于功效及其束缚,而不是功能。假如你在乎功能,应当用第三方库,如Google的protobuf-net。不管从功能、序列化了局的巨细仍是兼容性上,protobuf-net比这三者都要优异,固然,nothumanreadable。
Attribute请求
很多同类文章都宣称XmlSerializer和DataContractSerializer都请求在类上加响应的Attribute。但现实上并非如许。只要当你想要改动默许的序列化了局时,Attribute才是需要的。
最多见的一个毛病就是,给XmlSerializer要用到的类加SerializableAttribute。这个Attribute实际上是给BinaryFormatter和SoapFormatter用的,一样平常用在Remoting和Messaging上。
乱序读
乱序读的意义是,Deserialize的过程当中,不合错误Xml节点的按次做请求。Xml自己就是一种标志性的,带有声明性的言语,多半基于Xml的收集协定都不会对Xml节点的按次做请求。好比罕见的RSS,ATOM,OPDS等。
WCF利用的DataContractSerializer请求Xml节点按次要末严厉指定,要末按字母按次分列,也许有功能上思索,可是WCF的定位才是同意DataContractSerializer严厉请求Xml节点按次的基本缘故原由。WCF自己是用于通讯的,其对序列化的定位,仅仅只是动静传送的手腕,动静格局的严厉界说并没有甚么欠好,并且挪用方的代码都能够经由过程WSDL来天生,天然也就更不会呈现剖析时的成绩。以是不撑持乱序读完整是由其功效设定决意的。
XmlSerializer,在我看来能够做为ObjectXmlMapping的工具,固然要尽量撑持一切Xml的尺度。
自界说的撑持
XmlSerializer和DataContractSerializer都撑持IXmlSerializer接口。经由过程这个接口DataContractSerializer乃至能够撑持Attribute,可是,这实在已不是在利用DataContractSerializer的序列化机制了。并且在实践项目中也不具有可操纵性。以是在上表中,仍是把DataContractSerializer标志为不撑持XmlAttribute。
另有一些罕见的接口,如ISerializable和IDeserializationCallback是给BinaryFormatter用的,以撑持自界说序列化的历程。这里我很奇异为了BinaryFormatter已撑持了OnDeserializedAttribute,为何另有这么个接口来供应类似的功效。
一些小的细节
两个Xml序列化办法另有一些小的挺成心思的不同,我试图推测发生这类差别的缘故原由,却没想出来,也许是一些微软员工不为人知的计划理念,大概只是写代码时的顺心而为而已。
- XmlSerializer不序列化Null值,DataContractSerializer默许会序列化Null值。
- DataContractSerializer与Attribute:对没有任何Attribute的类,序列化一切Public的可读可写Property和Field;对仅仅加了SerializableAttribute的类,序列化一切可见性的Field(为了和BinaryFormatter举动分歧吗);假如仅仅加了DataContractAttribute,则甚么都不会序列化出来,必定要加DataMember。
- DataContract撑持序列只读属性,可是属性上要加DataMember.
- DataContractSerializer,仅仅加DataMember而不加DataContract会出非常。
- DataContractSerializer与ISerializable接口不兼容,间接抛非常。
- DataContractSerializer撑持IXmlSerializer接口,可是完成了这个接口,就不克不及加DataContract了。不然抛非常。这是甚么事理?
- XmlSerializer撑持乱序读的价值是,你不克不及把持你本人的天生的Xml的节点的按次。也就是说ElementNameAttribute中不克不及指定Order。
- BinaryFormatter请求被序列化的类必需“满城尽带Serializable”。以是假如你改不了源代码,序列化不了就是序列化不了。而XmlSerializable,你尽能够经由过程承继的体例,把Internal和Protected的Property序列化出来。
小结
基于下面的客不雅了局,信任你已有了本人的判别。我团体定见,DataContractSerializable就用在它应当用的中央吧,假如不是用WCF,仍是不要用它了,它的序列化了局有一些微软专属的工具。关于来自收集的松懈Xml接口数据,XmlSerializer是不贰之选。假如想把对象完全地保留上去(数据与形态),同时又不必要被人看。那就用BinaryFormatter吧。假如对功能或是数据巨细请求对照高,那这三个就都能用,用protobuff吧。
增补
这些信息算是一种履历,可是相对不合适作口试或是口试题用。
2012年6月2日:
发明一个不错的总结:
http://www.codeproject.com/Articles/255684/Create-and-Consume-RESTFul-Service-in-NET-Framewor前几天同学问我学习方向的问题。有点想法,不知道对不对,怕误导同学,现在“开源一下”。注:括号内是我现在整理的时填加上的。 |
|