SAX vs XmlTextReader - SAX em C #

Question

Eu estou tentando ler um documento XML grande e eu queria fazê-lo em pedaços vs caminho de XmlDocument de ler o arquivo inteiro na memória. Eu sei que eu posso usar XmlTextReader de fazer isso, mas eu queria saber se alguém tem usado SAX for .NET? Eu sei que os desenvolvedores Java jurar por ele e eu queria saber se vale a pena dar-lhe uma tentativa e em caso afirmativo, quais são os benefícios em usá-lo. Eu estou procurando detalhes.

Answer 1

Se você está falando sobre SAX para .NET , o projeto não parece ser mantida. O último lançamento foi mais de 2 anos atrás. Talvez eles conseguiram aperfeiçoar na última autorização, mas eu não apostaria nele. O autor, Karl Waclawek, parece ter desaparecido fora da rede.

Quanto SAX em Java? Pode apostar, é ótimo. Infelizmente, SAX não foi desenvolvido como um padrão, de modo que todas as portas não-Java têm vindo a adaptar a API Java para suas próprias necessidades. Enquanto DOM é um péssimo API bonita, tem a vantagem de terem sido projetadas para vários idiomas e ambientes, por isso é fácil de implementar em Java, C #, JavaScript, C, et al.

Answer 2

Se você quiser apenas para começar o trabalho feito rapidamente, existe o XmlTextReader para o efeito (em .NET).

Se você quer aprender um padrão de fato (e disponível em maio outras linguagens de programação) que é estável e que irá forçá-lo a um código muito eficiente e elegante, mas que também é extremamente flexível, então olhar em SAX. No entanto, não perca seu tempo, a menos que você vai ser a criação de analisadores XML altamente esotéricos. Em vez disso, olhar para analisadores que analisadores de próxima geração (como XmlTextReader) para sua plataforma específica.

Recursos SAX
SAX foi originalmente escrito para Java, e você pode encontrar o projeto de código aberto original, que tem sido estável por vários anos, aqui: http://sax.sourceforge.net/

Há um C # porta do mesmo projeto aqui (com documentos HTML como parte do download source); é também estável: http://saxdotnet.sourceforge.net/

Se você não gosta da implementação C #, você pode sempre recorrer a referência COM DLLs via ComInterop usando MSXML3 ou mais tarde: http://msdn.microsoft.com/en-us/library/ms994343.aspx

Os artigos que vêm do mundo Java, mas que provavelmente ilustram os conceitos que você precisa para ser bem sucedido com esta abordagem (há também pode ser baixado código-fonte Java que pode ser útil e pode ser fácil o suficiente para converter em C #):

• saída de documentos XML grandes, Parte 1 ( http: // www .ibm.com / developerworks / xml / biblioteca / x-tipbigdoc.html )
• saída de documentos XML grandes, Part 2 ( http: // www .ibm.com / developerworks / xml / biblioteca / x-tipbigdoc2.html )
• Use um filtro SAX para manipular dados ( http: // www. ibm.com/developerworks/xml/library/x-tipsaxfilter/ )

Será uma implementação complicada. Eu tenho usado apenas SAX para trás em meus pre-.NET dias, mas requer algumas técnicas de codificação bastante avançados. Neste ponto, é apenas não vale a pena.

conceito interessante para um analisador híbrido
Esta discussão descreve um analisador híbrido que usa o .NET XmlTextReader para implementar um analisador que fornece uma combinação de benefícios DOM e SAX ...
http://bytes.com/groups/net-xml/178403- XmlTextReader-versus-dom

Answer 3

Eu acredito que não há benefícios usando SAX pelo menos devido duas razões:

1. SAX é um modelo "push", enquanto XmlReader é um analisador pull que tem uma série de benefícios .
2. Sendo dependente de uma biblioteca de 3-parte em vez de usar uma API padrão NET.

Answer 4

Pessoalmente, eu prefiro muito mais o modelo de SAX como o XmlReader tem algumas armadilhas realmente irritantes que podem causar erros em seu código que possam causar seu código para pular elementos. A maioria dos códigos seria estruturado em torno de um tempo modelo (rdr.Read ()), mas se você tiver qualquer "ReadString" ou "ReadInnerXml ()" dentro desse loop que você vai encontrar-se pulando elementos na próxima iteração.

Como SAX é um evento baseado isso nunca vai hapen como você não pode executar qualquer operação que faria com que o seu analisador de buscar-frente.

O meu sentimento pessoal é que a Microsoft inventou a noção de que o XmlReader é melhor com a explicação do modelo de envio / recepção, mas eu realmente não comprá-lo. Portanto, a Microsoft acha que você não precisa criar um estado-máquina com XmlReader, que não faz sentido para mim, mas de qualquer maneira, é apenas minha opinião.