序列化 – Linq to Xml VS XmlSerializer VS DataContractSerializer

在我的web方法中，我得到了一些第三方C#实体类的对象。实体类只不过是DataContract。这个实体类是相当复杂的，具有各种类型的属性，一些属性也是集合。当然，这些链接类型也是DataContracts。

我想将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吗？如果是，为什么？

我会选择XmlSerializer，因为它对于自定义模式是最可维护的(假设你有XSD)。完成系统开发之后，请测试其性能，并确定XML序列化是否导致问题。如果是这样，你可以用需要更多工作的东西来替换它，然后再测试一下是否有任何的收获。但是如果XML序列化不是一个问题，那么你有可维护的代码。

与数据库或外部系统进行通信时，解析XML数据的小片段所需的时间可能是微不足道的。在具有大内存(16GB)的系统中，您可能会发现GC是.NET 4及更早版本(.NET 4.5尝试解决此问题)的瓶颈，特别是在处理非常大的数据集和流时。

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

关于LINQ to XML的一件好事是XSD validation.然而，这影响了性能。