Linq to Xml VS XmlSerializer VS DataContractSerializer

Question

在我看来web method,我得到了一些第三方C#实体类的对象.实体类只不过是DataContract.这个实体类非常复杂,具有各种类型的属性,一些属性也是集合.当然,这些链接类型也是DataContracts.

我想将该DataContract实体序列化为XML,作为我的Web服务的业务逻辑的一部分.我不能DataContractSerializer直接使用(在我在web方法中收到的对象),因为XML模式完全不同. 因此,DataContractSerializer生成的XML不会针对模式进行验证.

我无法总结出我应该遵循的方法来实施.我可以想到以下实施方法:

1. LINQ to XML - 这看起来不错,但我需要为每种类型的对象手动创建XML树(即类实例的元素或XML表示).由于有许多实体类并且它们彼此链接,我认为手动编写XML元素太多了.此外,当实体类引入一些新属性时,我将不得不继续修改XML树.不仅如此,我生成XML树的代码看起来有点笨拙(至少在外观上)并且将来很难被其他开发人员维护/更改; 他/她将不得不仔细研究它以了解如何生成XML.

2. XmlSerializer - 我可以编写自己的实体类来表示我想要的XML结构.现在,我需要将传入对象的详细信息复制到我自己的类的对象中.所以这是额外的工作(对于.NET,当代码执行时也是如此!).然后我可以XmlSerializer在我的对象上使用生成XML.在这种情况下,我将不得不创建实体类,每当第三方实体被修改时,我只需要在我的类中添加新属性.(使用XmlElement或XmlAttibute属性).但人们推荐DataContractSerializer这个,所以我不想最终确定这个,除非我清楚所有方面.

3. DataContractSerializer - 再次在这里,我将不得不编写自己的实体类,因为我无法控制第三方DataContracts.我需要将传入对象的细节复制到我自己的类的对象中.所以这是额外的工作.但是,由于DataContractSerializer不支持Xml属性,因此我必须IXmlSerializable在WriteXml方法中实现并生成所需的Xml .DataContractSerializer比XmlSerializer更快,但如果第三方实体发生变化,我将不得不处理更改(在WriteXml中).

问题:

• 考虑到性能,在这种情况下哪种方法最好？
• 你能建议一些更好的方法吗？
• 当传入的实体类可能发生变化时,是否DataContractSerializer值得考虑(因为它具有更好的性能XmlSerilaizer)？
• LINQ应该真的用于序列化吗？或者除了查询之外的其他内容真的有用吗？
• 在这种情况下,XmlSerializer可以优于LINQ吗？如果是,为什么？

Answer 1

我同意@Werner Strydom的回答.

我决定使用XmlSerializer因为代码变得可维护并且它提供了我期望的性能.最重要的是它让我完全控制XML结构.

这就是我解决问题的方法:

我根据我的要求创建了实体类(表示各种类型的Xml元素),并通过XmlSerializer传递了根类(表示根元素的类)的实例.

LINQ在1:M关系的情况下小用:

无论我Employee在特定节点(例如Department)下多次想要相同的元素(比如说),我都声明了类型的属性List<T>.例如public List<Employee> Employees在Department课堂上.在这种情况下,XmlSerializer显然在节点下添加了一个名为Employees(所有Employee元素的分组)的元素Department.在这种情况下,我使用LINQ(在XmlSerializer序列化.NET对象之后)来操纵XElement由XmlSerializer生成的(即XML).使用LINQ,我只是将所有Employee节点直接放在节点下Department并删除Employees节点.

但是,我通过组合xmlSerializer和得到了预期的表现LINQ.

缺点是,我创建的所有课程都必须公开,因为他们很可能是内部的!

为什么不DataContractSerializer和LINQ-to-XML？

• DataContractSerializer不允许使用Xml属性(除非我实现IXmlSerializable).请参阅DataContractSerializer支持的类型.
• LINQ-to-XML(并且IXmlSerializable)在创建复杂的XML结构时使代码变得笨拙,并且该代码肯定会让其他开发人员在维护/更改它时抓住他们的头脑.

还有其他方法吗？

• 是.正如@Werner Strydom所提到的,如果您对结果类感到满意,您可以使用Xsd2CodeXSD.exe或Xsd2Code等工具生成类,并直接使用它们.

Answer 2

我会选择XmlSerializer,因为它对于自定义架构来说是最易维护的(假设你有XSD).完成系统开发后,完整地测试其性能并确定XML序列化是否导致问题.如果是,您可以用需要更多工作的东西替换它并再次测试它以查看是否有任何收益.但是,如果XML序列化不是问题,那么您就拥有可维护的代码.

与与数据库或外部系统通信相比,解析一小段XML数据所花费的时间可以忽略不计.在具有大内存(16GB +)的系统上,您可能会发现GC是.NET 4及更早版本中的瓶颈(.NET 4.5尝试解决此问题),尤其是在处理非常大的数据集和流时.

使用AutoMapper将XSD.EXE创建的对象映射到实体.这将允许在不影响Web服务的情况下更改数据库设计.

关于LINQ to XML的一件好事是XSD验证.但是,这会影响性能.