Note that there are some explanatory texts on larger screens.

plurals
  1. POLinq to Xml VS XmlSerializer VS DataContractSerializer
    text
    copied!<p>In my <code>web method</code>, I get an object of some third party C# entity class. The entity class is nothing but the <code>DataContract</code>. This entity class is quite complex and has properties of various types, some properties are collections too. Of course, those linked types are also DataContracts. </p> <p><strong>I want to serialize that DataContract entity into XML</strong> as part of business logic of my web service. <strong>I cannot use <code>DataContractSerializer</code> directly (on the object I receive in the web method) simply because the XML schema is altogether different.</strong> So the XML generated by DataContractSerializer will not get validated against the schema. </p> <p>I am not able to conclude the approach I should follow for implementation. I could think of following implementation approaches:</p> <ol> <li><p><strong>LINQ to XML</strong> - This looks ok but I need to create XML tree (i.e. elements or XML representation of the class instance) manually for each type of object. Since there are many entity classes and they are linked to each other, I think this is too much of work to write XML elements manually. Besides, i'll have to keep modifying the XML Tree as and when the entity class introduces some new property. <strong>Not only this, the code where I generate XML tree would look little clumsy (at least in appearance) and would be harder to maintain/change by some other developer in future; he/she will have to look at it so closely to understand how that XML is generated.</strong></p></li> <li><p><strong>XmlSerializer</strong> - I can write my own entity classes that represent the XML structure I want. Now, I need to copy details from incoming object to the object of my own classes. <strong>So this is additional work (for .NET too when code executes!).</strong> Then I can use <code>XmlSerializer</code> on my object to generate XML. In this case, I'll have to create entity classes and whenever third party entity gets modified, I'll have to just add new property in my class. (with XmlElement or XmlAttibute attributes). <strong>But people recommend <code>DataContractSerializer</code> over this one and so I don't want to finalize this unless all aspects are clear to me.</strong></p></li> <li><p><strong>DataContractSerializer</strong> - Again here, I'll have to write my own entity class since I have no control over the third party DataContracts. And I need to copy details from incoming object to the object of my own classes. So this is additional work. However, since DataContractSerializer does not support Xml attributes, I'll have to implement <code>IXmlSerializable</code> and generate required Xml in <code>WriteXml</code> method. <strong>DataContractSerializer is faster than XmlSerializer, but again I'll have to handle the changes (in WriteXml) if third party entity changes.</strong></p></li> </ol> <p><strong>Questions:</strong></p> <ul> <li>Which approach is best in this scenario considering performance too?</li> <li>Can you suggest some better approach?</li> <li>Is <code>DataContractSerializer</code> worth considering (because it has better performance over <code>XmlSerilaizer</code>) when incoming entity class is subject to change?</li> <li>Should LINQ be really used for serialization? Or is it really good for things other than querying? </li> <li>Can XmlSerializer be preferred over LINQ in such cases? If yes, why?</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload