SAX vs XmlTextReader - SAX in C #

Question

Sto tentando di leggere un documento XML di grandi dimensioni e volevo farlo in blocchi rispetto al modo XmlDocument di leggere l'intero file in memoria. So di poter usare XmlTextReader per farlo, ma mi chiedevo se qualcuno ha usato SAX per .NET? So che gli sviluppatori Java lo giurano e mi chiedevo se vale la pena provarlo e, in caso affermativo, quali sono i vantaggi nell'usarlo. Sto cercando dettagli.

Answer 1

Se stai parlando di SAX per .NET , il progetto non sembra essere mantenuto. L'ultima versione è stata più di 2 anni fa. Forse l'hanno ottenuto perfetto sull'ultima versione, ma non ci scommetterei. L'autore, Karl Waclawek, sembra essere scomparso dalla rete.

Come per SAX in Java? Puoi scommettere, è grandioso. Sfortunatamente, SAX non è mai stato sviluppato come standard, quindi tutte le porte non Java hanno adattato un'API Java per le proprie esigenze. Sebbene DOM sia un'API piuttosto scadente, ha il vantaggio di essere stata progettata per più lingue e ambienti, quindi è facile da implementare in Java, C #, JavaScript, C, et al.

Answer 2

Se vuoi semplicemente completare il lavoro rapidamente, XmlTextReader esiste a tale scopo (in .NET).

Se vuoi imparare uno standard di fatto (e disponibile in altri linguaggi di programmazione) che sia stabile e che ti costringerà a scrivere codice in modo molto efficiente ed elegante, ma che è anche estremamente flessibile, allora guarda SAX. Tuttavia, non perdete tempo a meno che non stiate creando parser XML altamente esoterici. Cerca invece i parser che i parser di prossima generazione (come XmlTextReader) per la tua piattaforma particolare.

Risorse SAX
SAX è stato originariamente scritto per Java e puoi trovare il progetto open source originale, che è stato stabile per diversi anni, qui: http://sax.sourceforge.net/

C'è una porta C # dello stesso progetto qui (con documenti HTML come parte del download del sorgente); è anche stabile: http://saxdotnet.sourceforge.net/

Se non ti piace l'implementazione di C #, puoi sempre ricorrere al riferimento a DLL COM tramite COMInterop usando MSXML3 o successivo: http://msdn.microsoft.com/en-us/library/ms994343.aspx

Articoli che provengono dal mondo Java ma che probabilmente illustrano i concetti di cui hai bisogno per avere successo con questo approccio (potrebbe esserci anche un codice sorgente Java scaricabile che potrebbe rivelarsi utile e potrebbe essere abbastanza facile da convertire in C #):

• Output di documenti XML di grandi dimensioni, parte 1 ( http: // www .ibm.com / developerWorks / xml / library / x-tipbigdoc.html )
• Output di documenti XML di grandi dimensioni, parte 2 ( http: // www .ibm.com / developerWorks / xml / library / x-tipbigdoc2.html )
• Utilizza un filtro SAX per manipolare i dati ( http: // www. ibm.com/developerworks/xml/library/x-tipsaxfilter/ )

Sarà un'implementazione ingombrante. Ho usato SAX solo nei miei giorni pre.NET, ma richiede alcune tecniche di codifica piuttosto avanzate. A questo punto, non vale la pena.

Concetto interessante per un parser ibrido
Questo thread descrive un parser ibrido che utilizza .NET XmlTextReader per implementare un parser che fornisce una combinazione di vantaggi DOM e SAX ...
http://bytes.com/groups/net-xml/178403- XmlTextReader-versus-dom

Answer 3

Credo che non ci siano vantaggi nell'utilizzare SAX almeno per due motivi:

1. SAX è un "push " modello mentre XmlReader è un parser pull che ha una serie di vantaggi .
2. Essere dipendenti da una libreria di terze parti anziché utilizzare un'API .NET standard.

Answer 4

Personalmente, preferisco di gran lunga il modello SAX in quanto XmlReader ha alcune trappole davvero fastidiose che possono causare bug nel codice che potrebbero far saltare gli elementi. La maggior parte del codice verrebbe strutturata attorno a un modello while (rdr.Read ()), ma se si dispone di qualsiasi "quotString" o " ReadInnerXml () " all'interno di quel ciclo ti ritroverai a saltare elementi nella prossima iterazione.

Poiché SAX è basato sugli eventi, ciò non si verificherà mai poiché non è possibile eseguire alcuna operazione che induca il parser a cercare avanti

La mia sensazione personale è che Microsoft abbia inventato l'idea che XmlReader è migliore con la spiegazione del modello push / pull, ma non lo compro davvero. Quindi Microsoft pensa che non sia necessario creare una macchina a stati con XmlReader, non ha senso per me, ma comunque è solo la mia opinione.