我想将DataContract实体序列化为XML作为我的Web服务业务逻辑的一部分。我不能直接使用DataContractSerializer(在Web方法中收到的对象),因为XML模式完全不一样。因此,DataContractSerializer生成的XML将不会针对模式进行验证。
我不能总结我应该遵循的做法。我可以想到以下实施方法:
> LINQ to XML – 这看起来不错,但是我需要为每种类型的对象手动创建XML树(即类实例的元素或XML表示)。由于有很多实体类并且彼此链接,我认为手动编写XML元素太多了。此外,当实体类引入一些新的属性时,我将不得不继续修改XML Tree。不仅如此,我生成XML树的代码看起来很笨拙(至少在外观上),并且将来更难维护/改变其他开发人员;他/她将必须仔细查看,以了解XML的生成方式。
> XmlSerializer – 我可以编写自己的实体类来表示我想要的XML结构。现在,我需要将细节从传入的对象复制到我自己的类的对象。所以这是额外的工作(对于.NET,当代码执行时)!然后我可以在我的对象上使用XmlSerializer生成XML。在这种情况下,我必须创建实体类,并且当第三方实体被修改时,我必须在我的类中添加新的属性。 (使用XmlElement或XmlAttibute属性)。但是,人们推荐使用DataContractSerializer,所以我不想最终确定这一点,除非所有方面都清楚。
> DataContractSerializer – 再次,我必须编写自己的实体类,因为我无法控制第三方DataContracts。我需要将传入的对象的细节复制到我自己的类的对象。所以这是额外的工作。但是,由于DataContractSerializer不支持Xml属性,所以我必须实现IXmlSerializable并在WriteXml方法中生成所需的Xml。 DataContractSerializer比XmlSerializer快,但是如果第三方实体发生变化,我又需要处理更改(在WriteXml中)。
问题:
>考虑到性能,在这种情况下哪种方法最好?
你能建议一些更好的方法吗?
> DataContractSerializer值得考虑(因为它具有比XmlSerilaizer更好的性能),当传入的实体类有可能会改变?
LINQ是否真的用于序列化?还是查询以外的其他事情真的很好吗?
>在这种情况下,XmlSerializer可以优于LINQ吗?如果是,为什么?
与数据库或外部系统进行通信时,解析XML数据的小片段所需的时间可能是微不足道的。在具有大内存(16GB)的系统中,您可能会发现GC是.NET 4及更早版本(.NET 4.5尝试解决此问题)的瓶颈,特别是在处理非常大的数据集和流时。
使用AutoMapper将由XSD.EXE创建的对象映射到您的实体。这将允许数据库设计更改而不影响Web服务。
关于LINQ to XML的一件好事是XSD validation.然而,这影响了性能。