Vantagens do XSLT ou LINQ para XML

Question

Que vantagens existem para usar o XSLT ou LINQ para XML para análise HTML em C#? Isso está sob a suposição de que o HTML foi limpo para que seja válido XHTML. Esses valores eventualmente entrarão no objeto AC# para serem validados e processados.

Informe -me se isso é válido e se há outras coisas a considerar.

Vantagens XSLT:

• Fácil de mudar rapidamente e implantar
• Razoavelmente bem conhecido

Desvantagens XSLT:

• Não compilado, então é mais lento para processar
• A manipulação de cordas pode ser complicada
• Será mais desafiador entrar no objeto C# no final

Vantagens de Linq para XML:

• Compilado, então corre mais rápido
• Permite melhor manipulação de cordas

Linq para XML Desvantagens:

• Deve ser compilado para atualização

EDIT: Devo esclarecer, quero que eles sejam executados a longo prazo e o site pode atualizar o layout de vez em quando. Essa foi uma das maiores razões pelas quais pensei em usar algo que não exigia compilação.

Answer 1

Sem saber ainda mais o seu caso de uso, é difícil fornecer recomendações gerais.

De qualquer forma, você está comparando um pouco de maçãs e laranjas. O LINQ para XML (e LINQ em geral) é uma linguagem de consulta, enquanto o XSLT é uma linguagem de programação para transformar estruturas de árvores XML. Estes são conceitos diferentes. Você usaria um idioma de consulta sempre que quiser extrair uma determinada informação específica de uma fonte de dados para fazer o que precisar fazer com ele (seja para definir campos em um objeto C#). Uma transformação, por outro lado, seria útil para converter uma representação XML de seus dados em outra representação XML.

Portanto, se seu objetivo é criar objetos C# a partir do XML, você provavelmente não deseja usar o XSLT, mas qualquer uma das outras tecnologias oferecidas pela estrutura .NET para processar dados XML: The Old XmlDocument, XmlReader, XPathDocument, XmlSerializer ou XDocument. Cada um tem suas vantagens e desvantagens especiais, dependendo do tamanho da entrada, complexidade de entrada, saída desejada etc.

Como você está lidando apenas com HTML, você também pode querer dar uma olhada no HTML Agility Pack no codeplex.

Answer 2

Como você vai para C#, em algum momento seus dados passarão pelo LINQ (ou algum outro código XML para .NET) de qualquer maneira, você também pode ficar lá.

A menos que você tenha algum motivo convincente para ir com o XSLT, como você já tem muita experiência ou a implantação favorece fortemente os arquivos de texto, mantenha tudo em um só lugar.

Answer 3

Na minha experiência, o XSLT é mais conciso e legível quando você está lidando principalmente com a reorganização e selecionando elementos XML existentes. XPath é curto e fácil de entender, e a sintaxe XML evita o lixo do seu código com XElement e XAttribute declarações. XSLT funciona bem como uma árvore XML transformar Língua.

No entanto, seu manuseio de cordas é ruim, o loop não é intuitivo e não há um conceito significativo de sub -rotinas - você não pode transformar a saída de outra transformação.

Portanto, se você deseja realmente mexer com o elemento e atribuir conteúdo, ele rapidamente fica aquém. Não há problema em usar ambos, incidentalmente - xslt para normalizar a estrutura (digamos, para garantir que todos table elementos têm tbody elementos) e Linq-para-xml para interpretá-lo. As possibilidades de correspondência condicional priorizadas significam que o XSLT é mais fácil de usar ao lidar com muitas correspondências semelhantes, mas distintas. O XSLT é bom na simplificação de documentos, mas está faltando muitos recursos básicos para serem suficientes por conta própria.

Depois de pular de todo o coração na onda Linq para XML, eu diria que ele tem menos sobreposição com o XSLT que pode parecer à primeira vista. (E eu adoraria positivamente ver uma implementação XSLT 2.0/XQuery 1.0 para .NET).

Em termos de desempenho, ambos os técnicos são rápidos. De fato, como é tão difícil expressar operações lentas, é improvável que você acabe acidentalmente um caso lento no XSLT (a menos que você comece a brincar com recursão ...). Por outro lado, o LinQ to XML Power também pode tornar lento: basta usar qualquer objeto .NET pesado em algum loop interno e você terá um problema de desempenho emergente.

Faça o que fizer, não tente abusar do XSLT usando -o para executar qualquer coisa, exceto a lógica mais simples: é muito mais prolixo e muito menos legível que o C#equivalente. Se você precisar de um monte de lógica (até coisas simples como date > DateTime.Now ? "will be" : "has" Torne -se enormes hacks inchados no XSLT) e você não deseja usar o XSLT e o LINQ para XML, use o LINQ.

Answer 4

HTML Agility Pack?

Deixe-me tentar.

Answer 5

Você não deve usar qualquer Se você está apenas tentando analisar o HTML. Html! = Xml e não pode ser tratado da mesma forma. Por exemplo, a sequência de fuga '' é perfeitamente válida no HTML, mas não é uma entidade válida dentro de um documento XML válido (sem mexer severo com DTDs etc.). Isso vai te morder, acredite em mim!

Eu também recomendaria usar o HTML Agility Pack - Biblioteca brilhante.