- 7.1 Overview
- 7.2 The Sample Application
- 7.3 LINQ to XML
- 7.4 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.3 LINQ to XML
Since the earliest planning stages of .NET, Microsoft has been authoring classes to provide XML support for developers, introducing new classes, and refining old ones to keep pace with the ever-evolving World Wide Web Consortium specifications. With the release of .NET 2.0, developers were presented with an enormous amount of XML support, as Table 7.3 illustrates. This raises the obvious question: Why add even more XML support?
Table 7.3. XML Support in .NET 2.0
|
Feature |
Classes |
Comments |
|
Readers and writers |
XmlReader, XmlWriter |
Reads/writes XML to and from a stream one node at a time. Tedious to program for. Used by other classes to retrieve and store XML |
|
Schema validation |
XmlReader |
Warns of, or rejects, incoming XML that does not comply with the specified schema |
|
Document objects |
XmlDocument or XPathDocument, plus various node classes and other supporting classes |
Holds an entire XML document or fragment in memory. Provides XPath querying of the document. May provide for modification of document contents |
|
XSLT transformations |
XslTransform |
Provides for the transformation of an XML document into XML of a different format or into HTML or into any text format |
|
XML serialization |
Generic classes |
Provides for object content to be serialized/deserialized to and from a stream |
The answer is this: Microsoft is committed to providing LINQ support for collections of objects, including collections of XML objects; that is, support for XML documents. And since an XML document is a collection of XML objects—attributes, elements, directives, comments, and so on—LINQ to XML became a highly desirable feature, and highly desirable features make it into the released product.
Unlike LINQ to Datasets, which did not require the development of new ADO.NET classes, LINQ to XML did require that new XML classes be written. If you think back to our discussion of LINQ to Datasets, you will remember that our LINQ queries were performed against data tables, the same DataTable class that existed in .NET 2.0. The simple rectangular structure of a DataTable combined with its already existing implementation of IEnumerable (actually, its implementation of the even more LINQable IListSource interface) made it a natural for LINQ implementation.
The same cannot be said for the XmlDocument and XPathDocument classes. First, their hierarchical structure is more complex than relational, preventing them from providing a generic enumeration. And second, their specific enumerations have already been defined and not by Microsoft. These enumerations have been defined by the World Wide Web Consortium, and developers know them as axes, such as Descendant, Child, and Ancestor-or-self. Therefore, new classes that paralleled the old XML document and XPath classes and that provided LINQ syntax for making XPath selections were added to .NET.
These classes, referred to as the X classes, duplicate some capabilities that already existed in .NET 2.0, such as loading an XML document from a stream into a document object, saving an XML document from a document object to a stream, and querying/modifying the nodes of a document. What the X classes add to .NET is LINQ syntax for specifying XPath queries and very flexible constructors. That might not seem like much of an addition, but it is. To see why, consider that XDocuments and XElements can be constructed from the following:
- An incoming XML stream
- Literal values
- An object
- A collection of objects
- A collection of objects that each contains collections of objects
- The output from a LINQ to Objects query
It is a somewhat deliberately redundant list, but it all comes down to this: It is easier than it has ever been for a smart-device application to selectively gather and arrange any information that exists anywhere in that application and deliver it to a remote recipient, or to the device store as XML in any format. It is a strong claim, so we best support it with some code.
The first capability we want to illustrate is constructing an XElement object from literal values. It is not a common need, but the code to do it most clearly illustrates the creation of inner elements and attributes as part of the total construction. Listing 7.15 shows the code for creating an Employees element that contains three child Employee elements, each of which contains one attribute and three child elements.
Listing 7.15. Creating an Employees Element
XElement xmlEmployees =
new XElement("Employees",
new XElement("Employee",
new XAttribute("EmployeeId", "10"),
new XElement("FirstName", "John"),
new XElement("MiddleInitial", "B"),
new XElement("LastName", "Durant")),
new XElement("Employee",
new XAttribute("EmployeeId", "11"),
new XElement("FirstName", "Susan"),
new XElement("LastName", "Shank")),
new XElement("Employee",
new XAttribute("EmployeeId", "12"),
new XElement("FirstName", "John"),
new XElement("LastName", "Basilone"))
);
If we subsequently wished to expand our xmlEmployees XElement object into an XDocument object, perhaps because we were about to send it to a remote recipient and wanted to add a declaration, we would simply do this:
XDocument docEmployees =
new XDocument(
new XDeclaration("1.0", "utf-8", "yes"),
xmlEmployees);
If we want to create a new XElement object whose child elements consist of only those employees who have a middle initial, we execute a LINQ to XML query against docEmployees and construct a new document from the result. The LINQ to XML query to do this, and place the result into an XDocument named xmlEwMI, is as follows:
XElement xmlEwMI = new XElement("EmployeesWithMIs",
xmlEmployees
.Descendants("Employee")
.Where(EwMI =>
EwMI.Element("MiddleInitial") != null));
The corresponding XPath syntax, "//Employee[MiddleInitial]", is certainly more concise but not necessarily easier to understand or maintain. In general, LINQ to XML is easier to read, and XPath is more concise.
Now let's change our requirement a little bit. Instead of creating new XML from already-existing XML, as we have just done, we'll create an XElement from the output of a LINQ to Objects query. Think back to our application data, where we have an Employee object whose Orders property contains the collection of that employee's orders. We want to query that collection to obtain all the orders that shipped late, and store the result in an X object. In doing so, we want to specify which Order properties are to be captured and also specify what their XML types, attribute or element, and names will be. In addition, we want the orders to be sequenced by descending value. Once we have captured the information as XML, we wish to write it to a file in device storage. Listing 7.16 shows the code for doing this.
Listing 7.16. Selecting and Persisting Late Orders as XML
Employee employee = AppData.Current.Employees[EmployeeID];
string XmlFileName = @"My Documents\LateOrders.xml";
XElement xmlLateOrders;
xmlLateOrders =
new XElement(
"LateOrders",
employee.Orders
.Where(order => order.ShippedDate > order.RequiredDate)
.OrderByDescending(order => order.NetValue)
.Select(order => new XElement(
"Order",
new XAttribute("OrderID", order.OrderID),
new XAttribute("CustomerID", order.CustomerID),
new XAttribute("Value", order.NetValue),
new XElement("Ordered", order.OrderDate),
new XElement("Required", order.RequiredDate),
new XElement("Shipped", order.ShippedDate))
)
);
XDocument docLateOrders =
new XDocument(
new XDeclaration("1.0", "utf-8", "yes"),
xmlLateOrders);
docLateOrders.Save(XmlFileName);
When we run the application, we set a break point at the last line of code shown in Listing 7.16. When the application enters break mode, we use the XML visualizer to look into docLateOrders and see the results, as shown in Figure 7.12.
)
Figure 7.12 XML Generated from LINQ to Objects Query
Of all the features provided by LINQ to XML, the one that is illustrated in Listing 7.16 is the most beneficial and the greatest leap forward. No matter what application data must be exported, and no matter what XML format it must be in, you can provide it. And that is a nice capability indeed.
So, given the list of features mentioned in Table 7.1 plus the new features that we just covered, which ones should you focus on? Which ones are you must likely to use in your application? Our recommendation is this: If the XML that your application will be sending and receiving is of a known and unchanging syntax, use XML serialization and, if helpful, the supporting tools, such as XSD.EXE. If the schema of the data is unknown or unpredictable at design time, or if the subset of data that will be used cannot be determined until runtime, use LINQ to XML and LINQ to Objects. One way or the other, your application will be able to send, receive, and persist the XML data that other applications provide or require.