编辑:所说的标准类指的是 XmlDocument、XmlElement、XmlAttribute 等类。
当您使用XmlSerializer
时,会有许多限制:
这些限制经常迫使您做出某些设计决策,这些决策并不是在其他情况下您会做出的决策...而且,强制您做出糟糕的设计决策的工具通常不是一个好东西 ;)
话虽如此,当您需要快速将简单对象存储为XML格式时,它可以非常方便。我也喜欢它可以对生成的模式进行相当好的控制。
显然,它并不能给你完全控制输出。个人认为,LINQ to XML足以让我轻松手写这个过程,对于相对较小的项目,我很乐意用这种方式完成它。如果你正在使用.NET 3.5或4,但没有使用LINQ to XML,请立即尝试一下——它比旧的DOM好得多。
有时候,能够控制序列化和反序列化是很好的......特别是当你改变数据布局的时候。如果你不处于这种情况中,并且不预计会遇到这种情况,那么内置的XML序列化可能就可以胜任了。
编辑:我不认为XML序列化支持构建真正的不可变类型,而手工构建则显然是可行的。作为一个不可变性的粉丝,这肯定是我关注的问题之一。如果你实现了IXmlSerializable
接口,我相信你可以做到public不可变性,但你仍然必须是私有可变的。当然,我可能是错的——但这值得检查。
我认为XmlSerializer的主要缺点有:
1)对于涉及集合的复杂对象图,有时使用序列化控制属性很难获得您想要的XML模式。
2)如果在应用程序的一个版本和下一个版本之间更改类定义,则文件将变得无法读取。
是的,我个人使用自动XML序列化 - 尽管最初使用DataContractSerializer是因为WCF(即使没有任何属性也能够序列化类型非常有帮助),因为它不会嵌入类型。当然,因此在加载时需要知道您正在反序列化的对象类型。
这其中的大问题是,如果不实现IXmlSerializable,很难将其序列化为属性,或者暴露一些其他类型,以便序列化程序可以本地处理。
我想最大的陷阱是您无法自动序列化接口,因为DCS希望在接收到XML后能够重新构造实例。但是,标准集合接口是本地支持的。
总的来说,我发现DCS路线是最快且最无痛的方式。
作为替代方案,您还可以使用Linq to XML读取和写入XML,如果您想要完全控制 - 但是您仍然必须逐个成员地处理类型。
最近我一直在研究它(之前一直避免它,因为我看不出意义),在阅读Jon Skeet新书的早期版本后,我必须说 - 我对它如何轻松处理XML印象深刻。
我过去经常使用XmlSerializer,将来可能也会继续使用。然而,最大的陷阱已经在上面提到:
序列化器的限制(如限制为公共成员)要么1)对类施加与其主要功能无关的设计约束,要么2)强制增加解决这些约束的复杂性。
当然,其他方法的Xml序列化也会增加复杂性。
所以我想我的答案是,并没有适用于所有情况的正确或错误答案;选择序列化方法只是众多设计考虑之一。
有一些情况需要考虑。
除此之外 - 在正常情况下我没有看到任何问题。与使用更低级别的解析器相比,使用XML序列化器处理更复杂的数据是更容易的方法。
当您想要传输大量数据且资源非常有限时。