Linq to Xml VS XmlSerializer VS DataContractSerializer

В моем веб-методея получаю объект какой-то сторонней сущности C# сорт. Класс сущности — это не что иное, как DataContract. Этот класс сущностей довольно сложен и имеет свойства различных типов, некоторые свойства также являются коллекциями. Конечно, эти связанные типы также являются DataContracts.

Я хочу сериализовать этот объект DataContract в XMLкак часть бизнес-логики моего веб-сервиса.Я не могу использовать DataContractSerializerнапрямую (в объекте, который я получаю в веб-методе) просто потому, что схема XML совершенно другая. Таким образом, XML, сгенерированный DataContractSerializer, не будет проверен на соответствие схеме.

Я не могу определить подход, которому я должен следовать при реализации. Я мог бы придумать следующие подходы к реализации:

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и сгенерировать требуемый Xml в методе WriteXml. DataContractSerializer работает быстрее, чем XmlSerializer, но опять же мне придется обрабатывать изменения (в WriteXml), если изменится сторонний объект.

Вопросы:

• Какой подход лучше всего подходит для этого сценария с учетом производительности?
• Можете ли вы предложить лучший подход?
• Стоит ли рассматривать DataContractSerializer(потому что он имеет более высокую производительность по сравнению с XmlSerilaizer), когда входящий класс объекта может быть изменен?
• Следует ли действительно использовать LINQ для сериализации? Или это действительно хорошо для вещей, отличных от запросов?
• Можно ли в таких случаях использовать XmlSerializer вместо LINQ? Если да, то почему?