Wednesday at TechEd was another “linqy” day for me. In the morning I joined the session “LINQ to XML“, with speaker Mike Taulty. With LINQ to XML there is a new XML-API as Part of .NET 3.5 which sits in the namespace System.Xml.Linq. LINQ to XML makes it easy to create and edit XML documents without using additional syntax like XPATH or XSLT, but, of course, LINQ to XML won’t replace the existing APIs implemented in classes like XmlDocument, XmlReader, XmlWriter or XPathNavigator. It’s just another XML-API that let’s you use LINQ queries on top of XML.

Mike Taulty showed that LINQ to XML is much closer to XML than the other XML-APIs as part of the .NET Framework. When you create a XML-document with the new API, you can see that your C#-Code is really close to the XML (if you format your code like below and additionally put the XAttribute-Elements on the same line as the XElements they belong to (I hadn’t enough space to do so :-))):

XDocument doc = 
  new XDocument(
    new XElement("TrivadisLocations",
      new XElement("Location",
        new XAttribute("City","Basel"),
        new XElement("Consultants",
          new XElement("Consultant",
            new XAttribute("FirstName", "Thomas"),
            new XAttribute("LastName", "Huber")
          ),
          new XElement("Consultant",
            new XAttribute("FirstName", "Christoph"),
            new XAttribute("LastName", "Pletz")
          )
        )
      ),
      new XElement("Location",
        new XAttribute("City", "Freiburg"),
        new XElement("Consultants",
          new XElement("Consultant",
            new XAttribute("FirstName", "Thomas"),
            new XAttribute("LastName", "Wukasch")
          )
        )
      ),
      new XElement("Location",
        new XAttribute("City","Zürich"),
        new XElement("Consultants",
          new XElement("Consultant",
            new XAttribute("FirstName", "Patrick"),
            new XAttribute("LastName", "Spieler")
          )
        )
      )
    )
  );

doc.Save("locations.xml");

The XML generated from the code above looks like this:

<?xml version="1.0" encoding="utf-8"?>
<TrivadisLocations>
  <Location City="Basel">
    <Consultants>
      <Consultant FirstName="Thomas" LastName="Huber" />
      <Consultant FirstName="Christoph" LastName="Pletz" />
    </Consultants>
  </Location>
  <Location City="Freiburg">
    <Consultants>
      <Consultant FirstName="Thomas" LastName="Wukasch" />
    </Consultants>
  </Location>
  <Location City="Zürich">
    <Consultants>
      <Consultant FirstName="Patrick" LastName="Spieler" />
    </Consultants>
  </Location>
</TrivadisLocations>

OK, of course, writing XML is not such an amazing thing if you have a query language like LINQ. Reading XML would be more exciting. So let’s say you want to read the XML-file we’ve just created above and you want to get out each location-City where a “Thomas” works. You can just load the document by calling the static Load-Method of the XDocument-class and create a query on top of that document:

XDocument doc = XDocument.Load("locations.xml");

var query = 
  from c in doc.Descendants("Consultant")
  where c.Attribute("FirstName").Value == "Thomas"
  select c.Ancestors("Location")
         .Attributes("City").First().Value;

foreach (string city in query)
{
  Console.WriteLine(city);
}

The Output on the Console is

Basel
Freiburg

With the query above you get the cities more than one time if there are more than one “Thomas” in one location. Fortunately the XML above has exactly one or none in each location. By using a simple group by you won’t get any cities more than one time, even if there are more than one “Thomas” in a location:

XDocument doc = XDocument.Load("locations.xml");

var query =
  from c in doc.Descendants("Consultant")
  where c.Attribute("FirstName").Value == "Thomas"
  group c
  by c.Ancestors("Location")
      .Attributes("City").First().Value
    into grouping
    select grouping.Key;

foreach (string city in query)
{
  Console.WriteLine(city);
}

In the afternoon I joined the Session “Entity Framwork: Application Patterns“, with speaker Pablo Castro. If you’ve already had a look at the Entity Framework, maybe you were just thinking about the DataContext class. What is it with this class? Do you keep it in a stateful DataAccessLayer, or is it stateless and you create it each time the BusinessLayer accesses you DataAccessLayer? Pablo’s answer is that it’s stateless. The DataContext knows the structure and metadata of the underlying database, but it has no state and it is very thin. So in every method like “GetCustomerById(Guid customerID)”, you would create a new instance of the DataContext. Normally you would create the DataContext in the header of a using-block, so that it’s automatically disposed at the end of that block.