Vantaggi di XSLT o Linq to XML

Question

Quali vantaggi ci sono nell'usare XSLT o Linq in XML per l'analisi HTML in C#? Questo è sotto il presupposto che l'html è stato pulito in modo che sia valido xhtml. Questi valori andranno infine in un oggetto C# per essere convalidati ed elaborati.

Per favore fatemi sapere se questi sono validi e se ci sono altre cose da considerare.

XSLT Vantaggi:

• Facile da cambiare rapidamente e implementare
• abbastanza noto

Svantaggi XSLT:

• Non compilato, così è più lento di elaborare
• La manipolazione delle stringhe può essere cumulativa Mi
• Sarà più difficile entrare nel # oggetto C alla fine

LINQ to Vantaggi XML:

• compilato, in modo che sia più veloce
• consente di manipolare meglio stringa

Da Linq a XML Svantaggi:

• deve essere compilato per l'aggiornamento

Edit: vorrei chiarire, voglio questi per funzionare a lungo termine di un sito può aggiornare la loro disposizione, una volta ogni tanto. Questa era una delle ragioni più grandi che pensavo di usare qualcosa che non richiedeva la compilazione.

Answer 1

Senza ulteriori informazioni sul vostro caso d'uso è difficile dare consigli generali.

In ogni caso, si sta un po 'paragonando mele e arance. LINQ to XML (e LINQ in generale) è un linguaggio di query mentre XSLT è un linguaggio di programmazione per trasformare strutture di strutture XML. Questi sono concetti diversi. Si utilizzerà un linguaggio di query ogni volta che si desidera estrarre una determinata informazione specifica da un'origine dati per fare tutto ciò che è necessario (ad esempio per impostare campi in un oggetto C#). Una trasformazione, al contrario, sarebbe utile per convertire una rappresentazione XML dei dati in un'altra rappresentazione XML.

Quindi, se il vostro scopo è quello di creare C# oggetti da XML, probabilmente non si vuole utilizzare XSLT, ma nessuna delle altre tecnologie offerte da .NET Framework per elaborare i dati XML: il vecchio XmlDocument, XmlReader, XPathDocument, XmlSerializer o XDocument.Ognuno ha i suoi vantaggi e svantaggi speciali, a seconda delle dimensioni dell'input, della complessità dell'input, dell'output desiderato ecc.

Poiché si ha a che fare solo con l'HTML, si potrebbe anche dare un'occhiata allo HTML Agility Pack su CodePlex.

Answer 2

Dato che stai andando in C#, ad un certo punto i tuoi dati passeranno attraverso Linq (o qualche altro codice XML per .NET) in ogni caso, puoi anche metterli tutti lì.

A meno che non si abbia una ragione convincente per andare con XSLT, ad esempio se si ha già molta esperienza o l'implementazione favorisce fortemente lo sviluppo dei file di testo, tenerlo tutto in un unico posto.

Answer 3

Non utilizzare se si sta tentando di analizzare l'HTML. HTML! = XML e non può essere trattato allo stesso modo. Ad esempio la sequenza di escape "& nbsp;" è perfettamente valido in HTML, ma non è un'entità valida all'interno di un documento XML valido (senza problemi con DTD, ecc.). Questo ti morderà, credimi!

Si consiglia inoltre di utilizzare la libreria HTML Agility pack - brillante.

Answer 4

HTML Agility pack?

Lasciami provare.

Answer 5

Nella mia esperienza, XSLT è più conciso e leggibile quando si tratta principalmente di riorganizzare e selezionare elementi xml esistenti. XPath è breve e facile da capire, e la sintassi xml evita di sporcare il tuo codice con le dichiarazioni XElement e XAttribute. XSLT funziona correttamente come albero xml transform lingua.

Tuttavia, la gestione delle stringhe è scarsa, il ciclo non è intuitivo e non esiste un concetto significativo di subroutine: non è possibile trasformare l'output di un'altra trasformazione.

Quindi, se si vuole effettivamente giocherellare con elementi e attributi del contenuto, quindi rapidamente non è sufficiente. Non c'è alcun problema nell'usare entrambi, tra l'altro - XSLT per normalizzare la struttura (per esempio, per garantire che tutti gli elementi table abbiano elementi tbody) e linq-to-xml per interpretarlo. Le possibilità di corrispondenza condizionata prioritarie significano che XSLT è più facile da usare quando si ha a che fare con molte corrispondenze simili ma distinte. Xslt è bravo a semplificare i documenti, ma manca solo troppe funzioni di base per essere sufficiente da solo.

Avendo saltato con tutto il cuore sul carrozzone Linq-to-Xml, direi che ha meno sovrapposizioni con XSLT che potrebbe sembrare a prima vista. (E mi piacerebbe davvero vedere una implementazione XSLT 2.0/XQuery 1.0 per .NET).

In termini di prestazioni, entrambi i tecnici sono veloci. Infatti, poiché è così difficile esprimere operazioni lente, è improbabile che si inneschi casualmente un caso lento in XSLT (a meno che non inizi a giocare con la ricorsione ...). Al contrario, LINQ to Xml power può anche rallentare: basta usare qualsiasi oggetto .NET pesante in un loop interno e si ha un problema di prestazioni in erba.

Qualsiasi cosa tu faccia, non provare ad abusare di XSLT usandolo per eseguire qualsiasi cosa tranne la più semplice della logica: è molto più verboso e molto meno leggibile rispetto al C# equivalente. Se hai bisogno di un po 'di logica (anche le cose semplici come date > DateTime.Now ? "will be" : "has" diventano enormi hack gonfiati in XSLT) e non vuoi usare sia XSLT e Linq per Xml, usa Linq.