Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I agree with @Werner Strydom's answer. </p> <p><strong>I decided to use the <code>XmlSerializer</code></strong> because code becomes maintainable and it offers performance I expect. Most important is that it gives me full control over the XML structure.</p> <p><em>This is how I solved my problem:</em></p> <p>I created entity classes (representing various types of Xml elements) as per my requirement and passed an instance of the root class (class representing root element) through XmlSerializer. </p> <p><em>Small use of <code>LINQ</code> in case of 1:M relationship:</em></p> <p>Wherever I wanted same element (say <code>Employee</code>) many times under specific node (say <code>Department</code>) , I declared the property of type <code>List&lt;T&gt;</code>. e.g. <code>public List&lt;Employee&gt; Employees</code> in the <code>Department</code> class. In such cases XmlSerializer obviously added an element called <code>Employees</code> (which is grouping of all <code>Employee</code> elements) under the <code>Department</code> node. In such cases, I used <code>LINQ</code> (<em>after XmlSerializer serialized the .NET object</em>) to manipulate the <code>XElement</code> (i.e. XML) generated by XmlSerializer. Using <code>LINQ</code>, I simply put all <code>Employee</code> nodes directly under <code>Department</code> node and removed the <code>Employees</code> node.</p> <p>However, I got the expected performance by combination of <code>xmlSerializer</code> and <code>LINQ</code>. </p> <p>Downside is that, all classes I created had to be public when they could very well be internal!</p> <p><strong>Why not <code>DataContractSerializer</code> and <code>LINQ-to-XML</code>?</strong></p> <ul> <li><code>DataContractSerializer</code> does not allow to use Xml attributes (unless I implement <code>IXmlSerializable</code>). See the <a href="http://msdn.microsoft.com/en-us/library/ms731923.aspx" rel="noreferrer">types supported by DataContractSerializer</a>.</li> <li><code>LINQ-to-XML</code> (and <code>IXmlSerializable</code> too) makes code clumsy while creating complex XML structure and that code would definitely make other developers scratch their heads while maintaining/changing it.</li> </ul> <p><strong>Is there any other way?</strong></p> <ul> <li>Yes. As mentioned by @Werner Strydom, you can very well generate classes using <code>XSD.exe</code> or tool like <a href="http://xsd2code.codeplex.com/releases/view/22222" rel="noreferrer">Xsd2Code</a> and work directly with them if you are happy with the resulting classes.</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