Avantages de XSLT ou LINQ à XML

Question

Quels avantages y a-t-il pour utiliser XSLT ou LINQ à XML pour l'analyse HTML en C #? Ceci est en supposant que le HTML a été nettoyé, il est donc valide XHTML. Ces valeurs finiront par aller dans l'objet AC # pour être validé et traité.

Veuillez me faire savoir si ceux-ci sont valables et s'il y a d'autres choses à considérer.

Avantages XSLT:

• Facile à changer rapidement et à déployer
• Assez bien connu

Inconvénients XSLT:

• Non compilé, il est donc plus lent à traiter
• La manipulation des cordes peut être lourde
• Sera plus difficile d'entrer dans l'objet C # à la fin

Avantages LINQ à XML:

• Compilé, donc il fonctionne plus vite
• Permet une meilleure manipulation de cordes

Inconvénients de Linq à XML:

• Doit être compilé pour la mise à jour

EDIT: Je dois clarifier, je veux que ceux-ci s'exécutent à long terme et le site Web peut mettre à jour leur mise en page une fois un moment. C'était l'une des plus grandes raisons pour lesquelles je pensais utiliser quelque chose qui ne nécessitait pas de compilation.

Answer 1

Sans connaître votre cas d'utilisation, il est difficile de vous donner des recommandations générales.

Quoi qu'il en soit, vous comparez quelque peu des pommes et des oranges. LINQ à XML (et LINQ en général) est un langage de requête tandis que XSLT est un langage de programmation pour transformer les structures d'arborescence XML. Ce sont des concepts différents. Vous utiliseriez un langage de requête chaque fois que vous souhaitez extraire une certaine information spécifique d'une source de données pour faire tout ce que vous devez en faire (que ce soit pour définir des champs dans un objet C #). Une transformation, en revanche, serait utile pour convertir une représentation XML de vos données en une autre représentation XML.

Donc, si votre objectif est de créer des objets C # à partir de XML, vous ne voulez probablement pas utiliser XSLT mais toutes les autres technologies offertes par le Framework .NET pour traiter les données XML: l'ancien XmlDocument, XmlReader, XPathDocument, XmlSerializer ou XDocument. Chacun a ses avantages et inconvénients particuliers, selon la taille de l'entrée, la complexité des entrées, la sortie souhaitée, etc.

Puisque vous avez affaire à HTML uniquement, vous voudrez peut-être également jeter un œil au Pack d'agilité HTML sur codeplex.

Answer 2

Étant donné que vous allez à C #, à un moment donné, vos données vont passer par LINQ (ou un autre code XML pour .NET) de toute façon, vous pouvez aussi bien y mettre le tout.

À moins que vous ayez une raison impérieuse d'aller avec XSLT, comme vous avez déjà beaucoup d'expérience ou que le déploiement favorise fortement le déploiement des fichiers texte, gardez tout cela en un seul endroit.

Answer 3

D'après mon expérience, XSLT est plus concis et lisible lorsque vous avez principalement affaire à réorganiser et à sélectionner des éléments XML existants. XPath est court et facile à comprendre, et la syntaxe XML évite de joncher votre code avec XElement et XAttribute instructions. XSLT fonctionne bien comme un arbre XML transformer Langue.

Cependant, sa gestion des cordes est mauvaise, la boucle n'est pas intuitive et il n'y a pas de concept significatif de sous-programmes - vous ne pouvez pas transformer la sortie d'une autre transformation.

Donc, si vous voulez réellement jouer avec l'élément et attribuer du contenu, alors il échoue rapidement. Il n'y a aucun problème à utiliser les deux, d'ailleurs - XSLT pour normaliser la structure (disons, pour s'assurer que tout table Les éléments ont tbody éléments), et linq-to-xml pour l'interpréter. Les possibilités de correspondance conditionnelle prioritaires signifient que XSLT est plus facile à utiliser lorsqu'il s'agit de nombreuses correspondances similaires mais distinctes. XSLT est bon dans la simplification des documents, mais il manque simplement trop de fonctionnalités de base pour être suffisante en soi.

Ayant sauté de tout cœur dans le train Linq-XML, je dirais qu'il a moins de chevauchement avec XSLT qui pourrait sembler à première vue. (Et j'adorerais positivement voir une implémentation XSLT 2.0 / XQuery 1.0 pour .NET).

En termes de performances, les deux techniciens sont rapides. En fait, comme il est si difficile d'exprimer des opérations lentes, il est peu probable que vous déclenchez accidentellement un cas lent dans XSLT (sauf si vous commencez à jouer avec la récursivité ...). En revanche, Linq to XML Power peut également le rendre ralenti: utilisez simplement n'importe quel objet .NET lourd dans une boucle intérieure et vous avez un problème de performance en herbe.

Quoi que vous fassiez, n'essayez pas d'abuser de XSLT en l'utilisant pour effectuer autre chose que la logique la plus simple: c'est beaucoup plus verbeux et beaucoup moins lisible que le C # équivalent. Si vous avez besoin d'un tas de logique (même des choses simples comme date > DateTime.Now ? "will be" : "has" Devenez d'énormes hacks gonflés dans XSLT) et vous ne voulez pas utiliser à la fois XSLT et LINQ en XML, utilisez LINQ.

Answer 4

Pack d'agilité HTML?

Laisse-moi essayer.

Answer 5

Tu ne devrais pas utiliser Soit Si vous essayez juste d'analyser HTML. Html! = Xml et ne peut pas être traité de la même manière. Par exemple, la séquence d'échappement '' est parfaitement valide dans HTML mais n'est pas une entité valide dans un document XML valide (sans gâcher sévère avec DTDS, etc.). Cela vous mordra, croyez-moi!

Je recommanderais également d'utiliser le Pack d'agilité HTML - Brilliant Bibliothèque.