Sascha, ich kann deine Argumentation leider nicht ganz nachvollziehen
. Erst einmal ist XPathDocument genau für solche Zwecke gedacht, bei denen man kein fettes
DOM benötigt, sondern nur einen kleinen schnellen read-only Parser.
Zitat von
Sascha L:
Geht mich ja nichts an, aber "MoveNext" ist absolut unschön und fehlerträchtig. Überhaupt das durchgehen durch den
XML-Baum.
Wer sagt, foreach funktioniere nur mit XmlDocument
? Hier eine etwas schönere Variante meines Codes:
Code:
static void XPathDoc()
{
var productList = new List<ProductItem>();
var nav = new XPathDocument(new StringReader(
xml)).CreateNavigator();
foreach (XPathNavigator itemNav in nav.Select("/Catalog/Categories/Category[@name=\"" + name + "\"]/items/*")) {
ProductItem prodItem = new ProductItem {
Name = itemNav.GetAttribute("name", ""),
ShortDescription = itemNav.SelectSingleNode("shortdescription").Value,
LongDescription = itemNav.SelectSingleNode("longdescription").Value,
ItemIdentifier = itemNav.SelectSingleNode("itemIdentifier").Value,
};
productList.Add(prodItem);
}
}
Den Code könnte man natürlich auch auf das Element-fehlt-Handling von dir umstellen, aber das muss Luckie wissen.
Und ich sehe auch nicht, dass du im Gegensatz zu uns etwas anderes machst als "das durchgehen durch den
XML-Baum", oder wo du "komplett auf XPATH" setzt - genaugenommen sinds bei uns doch sogar 3 XPaths mehr
.
Zitat von
Sascha L:
Aber da selektiert man mit XPATH die Nodes oder den Node, [...]
Wie ich schon schrob,
man benutzt heute eher XLinq - wenns einem gefällt
.
Code:
static void LinqToXML()
{
var cat = XElement.Parse(
xml).Element("Categories").Elements("Category").Single(node => node.Attribute("name").Value == name);
var productList =
(from item in cat.Element("items").Elements()
select new ProductItem {
Name = item.Attribute("name").Value,
ShortDescription = item.Element("shortdescription").Value,
LongDescription = item.Element("longdescription").Value,
ItemIdentifier = item.Element("itemIdentifier").Value
}).ToList();
}
Manchen dürfte die Verbosity nicht gefallen, aber man kann immer noch entgegnen "hmmm, und wo genau in deinem Code ist nun ein Schutz gegen XPath-Injection?"
. Und in Sachen Performance ist nicht alles von 3.0+ miserabel...
Code:
1. LinqToXML 132 µs
2. XmlDoc 186 µs
3. XPathDoc 245 µs
Getestet mit 20 Produkten. Bei wenigern wird XPathDocument zweiter, mein Eingangssatz über dessen Performance dürfte damit trotzdem widerlegt sein
.
Um die Verwirrung zu komplettieren, sollte man noch Linq To XSD im Auge behalten. 6 Wege zum gleichen Ziel, _das_ ist .Net!