LINQ to XML vs. Other XML Technologies
This topic compares LINQ to XML to the following XML technologies: XmlReader, XSLT, MSXML, and XmlLite. This information can help you decide which technology to use.
For a comparison of LINQ to XML to the Document Object Model (DOM), see LINQ to XML vs. DOM.
LINQ to XML vs. XmlReader
XmlReader is a fast, forward-only, non-caching parser.
LINQ to XML is implemented on top of XmlReader, and they are tightly integrated. However, you can also use XmlReader by itself.
For example, suppose you are building a Web service that will parse hundreds of XML documents per second, and the documents have the same structure, meaning that you only have to write one implementation of the code to parse the XML. In this case, you would probably want to use XmlReader by itself.
In contrast, if you are building a system that parses many smaller XML documents, and each one is different, you would want to take advantage of the productivity improvements that LINQ to XML provides.
LINQ to XML vs. XSLT
Both LINQ to XML and XSLT provide extensive XML document transformation capabilities. XSLT is a rule-based, declarative approach. Advanced XSLT programmers write XSLT in a functional programming style that emphasizes a stateless approach. Transformations can be written using pure functions that are implemented without side effects. This rule-based or functional approach is unfamiliar to many developers, and can be difficult and time-consuming to learn.
XSLT can be a very productive system that yields high-performance applications. For example, some big Web companies use XSLT as a way to generate HTML from XML that has been pulled from a variety of data stores. The managed XSLT engine compiles XSLT to CLR code, and performs even better in some scenarios than the native XSLT engine.
However, XSLT does not take advantage of the C# and Visual Basic knowledge that many developers have. It requires developers to write code in a different and complex programming language. Using two non-integrated development systems such as C# (or Visual Basic) and XSLT results in software systems that are more difficult to develop and maintain.
After you have mastered LINQ to XML query expressions, LINQ to XML transformations are a powerful technology that is easy to use. Basically, you form your XML document by using functional construction, pulling in data from various sources, constructing XElement objects dynamically, and assembling the whole into a new XML tree. The transformation can generate a completely new document. Constructing transformations in LINQ to XML is relatively easy and intuitive, and the resulting code is readable. This reduces development and maintenance costs.
LINQ to XML is not intended to replace XSLT. XSLT is still the tool of choice for complicated and document-centric XML transformations, especially if the structure of the document is not well defined.
XSLT has the advantage of being a World Wide Web Consortium (W3C) standard. If you have a requirement that you use only technologies that are standards, XSLT might be more appropriate.
XSLT is XML, and therefore can be programmatically manipulated.
LINQ to XML vs. MSXML
MSXML is the COM-based technology for processing XML that is included with Microsoft Windows. MSXML provides a native implementation of the DOM with support for XPath and XSLT. It also contains the SAX2 non-caching, event-based parser.
MSXML performs well, is secure by default in most scenarios, and can be accessed in Internet Explorer for performing client-side XML processing in AJAX-style applications. MSXML can be used from any programming language that supports COM, including C++, JavaScript, and Visual Basic 6.0.
MSXML is not recommended for use in managed code based on the common language runtime (CLR).
LINQ to XML vs. XmlLite
XmlLite is a non-caching, forward only, pull parser. Developers primarily use XmlLite with C++. It is not recommended for developers to use XmlLite with managed code.
The main advantage of XmlLite is that it is a lightweight, fast XML parser that is secure in most scenarios. Its threat surface area is very small. If you have to parse untrusted documents and you want to protect against attacks such as denial of service or exposure of data, XmlLite might be a good option.
XmlLite is not integrated with Language-Integrated Query (LINQ). It does not yield the programmer productivity improvements that are the motivating force behind LINQ.