Vantaggi di XSLT o LINQ to XML

Question

Quali sono i vantaggi per utilizzando XSLT o LINQ to XML per l'analisi HTML in C #? Questo è sotto l'ipotesi che il codice HTML è stata pulita quindi è Valid XHTML. Questi valori finirà per andare in un oggetto c # per essere convalidati e trasformati.

Per favore fatemi sapere se queste sono valide e se ci sono altre cose da considerare.

XSLT Vantaggi:

• Facile cambiare rapidamente e distribuire
• abbastanza noto

Svantaggi XSLT:

• Non compilato, quindi è più lento di elaborare
• manipolazione stringa può essere ingombrante
• Sarà più difficile per entrare in oggetto C # alla fine

LINQ to XML Vantaggi:

• Compilato, in modo che sia più veloce
• consente una migliore manipolazione di stringhe

LINQ to XML Svantaggi:

• deve essere compilato per l'aggiornamento

Modifica: Vorrei chiarire, voglio questi per funzionare a lungo termine di un sito può aggiornare la loro disposizione, una volta ogni tanto. Questo è stato uno dei motivi più grande ho pensato di usare qualcosa che non richiedesse la compilazione.

Answer 1

Senza conoscere ulteriormente il caso d'uso è difficile dare raccomandazioni generali.

In ogni caso, si sta un po 'confrontando le mele e le arance. LINQ to XML (e LINQ in generale) è un linguaggio di query, mentre XSLT è un linguaggio di programmazione per trasformare strutture ad albero XML. Questi sono concetti diversi. Si potrebbe usare un linguaggio di query ogni volta che si desidera estrarre un certo pezzo specifico di informazioni da una fonte di dati per fare tutto ciò che devi fare con esso (sia per impostare i campi in un oggetto # C). Una trasformazione, al contrario, sarebbe utile per convertire la rappresentazione XML uno dei vostri dati in un altro 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 particolari vantaggi e svantaggi, a seconda delle dimensioni di ingresso, la complessità di ingresso, uscita desiderata etc.

Dal momento che avete a che fare solo con l'HTML, si potrebbe anche voler dare un'occhiata al HTML Agility pacchetto su CodePlex.

Answer 2

Dal momento che si sta andando a C #, ad un certo punto i dati sta per passare attraverso Linq (o qualche altro codice XML per .NET) in ogni caso, si può anche attaccare tutto lì.

A meno che non hai qualche motivo valido per andare con XSLT, come hai già un sacco di esperienza o la distribuzione favorisce fortemente stendere i file di testo, tenere tutto in un unico luogo.

Answer 3

Nella mia esperienza, XSLT è più conciso e leggibile quando si è in primo luogo si tratta di riordinare e selezionando gli elementi XML esistenti. XPath è breve e facile da capire, e la sintassi XML evita sporcare il codice con XElement e XAttribute dichiarazioni. XSLT funziona bene come un xml-albero trasformare lingua.

Tuttavia, è la gestione delle stringhe è scarsa, looping è poco intuitivo, e non c'è concetto significativo di subroutine -. Non è possibile trasformare l'uscita di un altro trasformare

Quindi, se si vuole perdere tempo in realtà con elementi e attributi contenuti, poi cade rapidamente breve. Non c'è nessun problema ad utilizzare entrambi, per inciso - XSLT per normalizzare la struttura (ad esempio, per garantire che tutti gli elementi table hanno tbody elementi), e LINQ to XML per interpretarlo. Le possibilità di corrispondenza condizionali priorità significano XSLT è più facile da usare quando si tratta di tante partite la classica ma distinti. XSLT è bravo a documento semplificazione, ma è solo manca troppe funzioni di base per essere di per sé sufficiente.

Avere saltò tutto il cuore sul carro Linq to Xml, direi che ha meno sovrapposizione con XSLT che potrebbe sembrare a prima vista. (E mi piacerebbe positivamente piace vedere un XSLT 2.0 / 1.0 XQuery implementazione per NET).

In termini di prestazioni, entrambi i tecnici sono veloci. In realtà, dal momento che è così difficile da esprimere operazioni lente, è improbabile per innescare accidentalmente un caso lenta in XSLT (a meno che non si inizia a giocare con la ricorsione ...). Al contrario, LINQ al potere Xml anche può fare con calma:. Basta usare qualsiasi oggetto .NET pesante in qualche ciclo interno e hai un problema di prestazioni in erba

Qualunque cosa tu faccia, non si tenta di abusare XSLT utilizzando per eseguire qualsiasi cosa, ma la più semplice delle logica: è il modo più prolisso e molto meno leggibile che l'equivalente C #. Se avete bisogno di un po 'di logica (anche cose semplici come date > DateTime.Now ? "will be" : "has" diventare enormi hack gonfio in XSLT) e non si desidera utilizzare sia XSLT e LINQ to XML, utilizzare Linq.

Answer 4

HTML Agility in valigia?

Vorrei provare.

Answer 5

You shouldn't use either if you are just trying to parse HTML. HTML != XML and cannot be treated the same. For instance the escape sequence ' ' is perfectly valid in HTML but is not a valid entity within a valid XML document (without severe messing around with DTDs etc). This will bite you, believe me!

I would also recommend using the HTML Agility pack - brilliant library.