Le moyen le plus rapide pour analyser des fichiers XML en C#?

La surcharge de lancer des exceptions probablement nains de la surcharge d'analyse XML. Vous avez besoin de réécrire le code pour qu'il ne jette pas des exceptions.

Une façon est de vérifier l'existence d'un élément avant de poser la question de sa valeur. Cela fonctionnera, mais c'est beaucoup de code. Une autre façon de faire serait d'utiliser une carte:

Dictionary<string, string> map = new Dictionary<string, string>
{
  { "matchtype", null },
  { "matches", null },
  { "ballsbowled", null }
};

foreach (XmlElement elm in stats.SelectNodes("*"))
{
   if (map.ContainsKey(elm.Name))
   {
      map[elm.Name] = elm.InnerText;
   }
}

Ce code permet de gérer tous les éléments dont les noms vous vous souciez et d'ignorer ceux qui ne le sont pas. Si la valeur de la carte est nulle, cela signifie qu'un élément de ce nom n'existait pas (ou n'avait pas de texte).

En fait, si vous affichez les données dans un DataTable, et les noms de colonne dans la DataTable sont les mêmes que les noms des éléments dans le document XML, vous n'avez même pas besoin de construire une carte, depuis le DataTable.Columns propriété est toute la carte dont vous avez besoin. Aussi, depuis le DataColumn sait quel type de données qu'il contient, vous n'avez pas à dupliquer cette connaissance dans votre code:

foreach (XmlElement elm in stats.SelectNodes("*"))
{
   if (myTable.Columns.Contains(elm.Name))
   {
      DataColumn c = myTable.Columns[elm.Name];
      if (c.DataType == typeof(string))
      {          
         myRow[elm.Name] = elm.InnerText;
         continue;
      }
      if (c.DataType == typeof(double))
      {
         myRow[elm.Name] = Convert.ToDouble(elm.InnerText);
         continue;
      }
      throw new InvalidOperationException("I didn't implement conversion logic for " + c.DataType.ToString() + ".");
   }
}

Remarquez comment je ne suis pas déclarer toutes les variables pour stocker cette information, donc il n'y a aucune chance de me foutre en l'air et la déclaration d'une variable d'un type de données différent de la colonne, il est stocké dans, ou la création d'une colonne dans ma table et en oubliant de mettre en œuvre la logique qui le remplit.

Modifier

Bon, voilà quelque chose qui est un peu tricksy. C'est une question assez technique courante en Python, en C#, je pense que la plupart des gens pensent encore il y a quelque chose de bizarre à ce sujet.

Si vous regardez le deuxième exemple que j'ai donné, vous pouvez voir que c'est à l'aide de la meta-information dans le DataColumn de comprendre à quelle logique à utiliser pour la conversion d'une valeur de l'élément de texte à son type de base. Vous pouvez accomplir la même chose à la construction de votre propre carte, par exemple:

Dictionary<string, Type> typeMap = new Dictionary<string, Type>
{
   { "matchtype", typeof(string) },
   { "matches", typeof(int) },
   { "ballsbowled", typeof(int) }
}

et ensuite de faire à peu près la même chose que j'ai montré dans le deuxième exemple:

if (typeMap[elm.Name] == typeof(int))
{
   result[elm.Name] = Convert.ToInt32(elm.Text);
   continue;
}

Vos résultats peuvent ne plus être un Dictionary<string, string>, car ils peuvent contenir des choses qui ne sont pas des chaînes; ils doivent être une Dictionary<string, object>.

Mais cette logique semble un peu maladroits; vous êtes à l'analyse de chaque élément plusieurs fois, il y a continue déclarations de sortir de celui - ci- il n'est pas terrible, mais il pourrait être plus concis. Comment? En utilisant une autre carte, celle que les cartes de types de fonctions de conversion:

Dictionary<Type, Func<string, object>> conversionMap = 
   new Dictionary<Type, Func<string, object>>
{
   { typeof(string), (x => x) },
   { typeof(int), (x => Convert.ToInt32(x)) },
   { typeof(double), (x => Convert.ToDouble(x)) },
   { typeof(DateTime), (x => Convert.ToDateTime(x) }
};

C'est un peu dur à lire, si vous n'êtes pas habitué à des expressions lambda. Le type Func<string, object> spécifie une fonction qui prend un string comme argument et retourne un objet. Et c'est ce que les valeurs de cette carte sont les suivants: ils sont les expressions lambda, c'est à dire des fonctions. Ils prennent un argument de type chaîne (x), et ils retournent un objet. (Comment savons-nous que x est une chaîne de caractères? Le Func<string, object> nous le dit.)

Cela signifie que la conversion d'un élément peut prendre une ligne de code:

result[elm.Name] = conversionMap[typeMap[elm.Name]](elm.Text);

Aller de l'intérieur vers l'extérieur d'expression, ce qui regarde le type de l'élément dans typeMap, et se penche ensuite la fonction de conversion en conversionMap, et les appels de fonction, en passant il elm.Text comme un argument.

Cela peut ne pas être l'approche idéale dans votre cas. Je ne sais vraiment pas. Je montre ici parce qu'il y a un problème plus important à jouer. Comme Steve McConnell points dans Code Complet, il est plus facile de données de débogage que c'est le débogage de code. Cette technique permet de désactiver la logique du programme dans les données. Il y a des cas où l'utilisation de cette technique simplifie grandement la structure de votre programme. Il vaut la peine de comprendre.

OriginalL'auteur Robert Rossney

Vous pouvez essayer de LINQ to XML. Ou vous pouvez utiliser cette à la figure ce qu'il faut utiliser.

OriginalL'auteur Chandam

Je ne dirais pas que LINQ est la meilleure approche. J'ai cherché sur Google et j'ai vu des références à HTML Agility Pack .

Je pense que si vous allez avoir un goulot d'étranglement de vitesse, ce sera avec votre processus de téléchargement. En d'autres termes, il semble que vos problèmes de performances ne sont pas avec votre code XML. Je pense qu'il y a des façons d'améliorer votre vitesse de téléchargement peut-être ou que votre fichier i/o, mais je ne sais pas ce qu'ils voudraient être.

OriginalL'auteur djangofan

Un XmlReader est la solution à votre problème. Un XmlDocument contient beaucoup de méta-informations qui rendent le Xml facile d'accès, mais il devient trop lourd sur la mémoire. J'ai vu certains Xmls de taille de moins de 50 KO converti à quelques mo (10 ou quelque chose) de XmlDocument.

OriginalL'auteur Sudesh Sawant