序列化 – Linq to Xml VS XmlSerializer VS DataContractSerial

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