¿Qué tiene de malo la creación de XML con la concatenación de cadenas?

Question

En el hilo What’s your favorite “programmer ignorance” pet peeve?, aparece la siguiente respuesta, con una gran cantidad de upvotes:

Programmers who build XML using string concatenation.

Mi pregunta es, ¿es la construcción de XML a través de la concatenación de cadenas (como un StringBuilder en C#) malo?

He hecho esto varias veces en el pasado, ya que a veces es la forma más rápida de llegar del punto A al punto B cuando se trata de las estructuras/objetos de datos con los que estoy trabajando. Hasta ahora, he encontrado algunas razones por las cuales este no es el mejor enfoque, ¿pero hay algo que estoy pasando por alto? ¿Por qué debería evitarse esto?

1. Probablemente la razón más importante que puedo pensar es que necesita escapar de sus cadenas manualmente, y la mayoría de los programadores nuevos (e incluso algunos programadores experimentados) lo olvidarán. Funcionará muy bien para ellos cuando lo prueben, pero luego "aleatoriamente" sus aplicaciones fallarán cuando alguien arroje un símbolo & en alguna parte. Ok, compraré esto, pero es realmente fácil evitar el problema (SecurityElement.Escape para nombrar uno).
2. Cuando hago esto, generalmente omito la declaración XML (es decir, <?xml version="1.0"?>). ¿Esto es dañino?
3. ¿Penalizaciones de rendimiento? Si sigue con la concatenación de cadenas adecuada (es decir, StringBuilder), ¿le preocupa esto? Presumiblemente, una clase como XmlWriter también necesitará hacer un poco de manipulación de cadenas ...
4. Existen formas más elegantes de generar XML, como usar XmlSerializer para serializar/deserializar automáticamente sus clases. Ok seguro, estoy de acuerdo. C# tiene un montón de clases útiles para esto, pero a veces no quiero hacer una clase para algo realmente rápido, como escribir un archivo de registro o algo así. ¿Esto solo soy yo perezoso? Si estoy haciendo algo "real", este es mi enfoque preferido para tratar con w/XML.

Answer 1

Puede terminar con XML no válido, pero no lo descubrirá hasta que lo vuelva a analizar, y entonces ya es demasiado tarde. Aprendí esto de la manera difícil.

Answer 2

Creo que el problema es que no está viendo el archivo xml como algo lógico de almacenamiento de datos, sino como un simple archivo de texto donde se escriben cadenas.

Es obvio que esas bibliotecas hacen la manipulación de cadenas para usted, pero la lectura/escritura de XML debe ser algo similar a datas más ahorro en una base de datos o algo parecido lógicamente

Answer 3

Si necesita XML trivial, entonces está bien. Solo el mantenimiento de la concatenación de cadenas se descompone cuando el xml se vuelve más grande o más complejo. Usted paga ya sea en el desarrollo o en el tiempo de mantenimiento. La elección es suya siempre, pero la historia sugiere que el mantenimiento siempre es más costoso y, por lo tanto, cualquier cosa que lo haga más fácil, en general vale la pena.

Answer 4

Como dijiste, no es fácil construir XML correctos usando la concatenación de cadenas, especialmente ahora que tienes XML linq que permite la construcción simple de un gráfico XML y que los espacios de nombres, etc. serán correctos.

Obviamente, importa el contexto y la forma en que se usa, como en el ejemplo de registro string.Format puede ser perfectamente aceptable.

Pero con demasiada frecuencia las personas ignoran estas alternativas cuando trabajan con gráficos XML complejos y simplemente usan un StringBuilder.

Answer 5

Necesita escapar de sus cadenas manualmente. Está bien. ¿Pero eso es todo? Claro, puedes poner la especificación XML en tu escritorio y verificar cada vez que hayas considerado todos los casos posibles cuando estás construyendo una cadena XML. O puede utilizar una biblioteca que encapsula este conocimiento ...

Answer 6

Siempre he pensado que crear un XML es más tarea que leer en uno. Nunca me he acostumbrado a la serialización, parece que nunca funciona para mis clases, y en lugar de pasar una semana tratando de que funcione, puedo crear un archivo XML usando cadenas en una mera fracción de tiempo y escribirlo fuera.

Y luego lo cargo utilizando un árbol XMLReader. Y si el archivo XML no se lee como válido, vuelvo y encuentro el problema dentro de mis rutinas de guardado y lo corrijo. Pero hasta que obtenga un sistema de guardar/cargar, me niego a realizar un trabajo de misión crítica hasta que sepa que mis herramientas son sólidas.

Supongo que se trata de preferencia del programador. Claro, hay diferentes maneras de hacer las cosas, seguro, pero para desarrollar/probar/investigar/depurar, esto estaría bien. Sin embargo, también limpiaría mi código y lo comentaría antes de entregárselo a otro programador.

Porque independientemente del hecho de que esté utilizando StringBuilder o XMLNodes para guardar/leer su archivo, si todo es un lío de galimatías, nadie va a entender cómo funciona.

Answer 7

Creo que la legibilidad, la flexibilidad y la escalabilidad son factores importantes. Considere el siguiente fragmento de LINQ to XML:

XDocument doc = new XDocument(new XDeclaration("1.0","UTF-8","yes"), 
    new XElement("products", from p in collection 
    select new XElement("product", 
     new XAttribute("guid", p.ProductId), 
     new XAttribute("title", p.Title), 
     new XAttribute("version", p.Version)))); 

se puede encontrar una manera de hacer que sea más fácil que esto? Puedo enviarlo a un navegador, guardarlo en un documento, agregar atributos/elementos en segundos y así sucesivamente ... simplemente agregando un par de líneas de código. Puedo hacer prácticamente todo sin mucho esfuerzo.

Answer 8

Otro punto contra el uso de la concatenación de cadenas es que la estructura jerárquica de los datos no es clara al leer el código. En el ejemplo de @ Sander de Linq-to-XML, por ejemplo, está claro a qué elemento primario pertenece el elemento "producto", a qué elemento se aplica el atributo "título", etc.

Answer 9

En realidad, encuentro el mayor problema con la concatenación de cadenas no está funcionando bien la primera vez, sino que se mantiene correcta durante el mantenimiento del código . Con demasiada frecuencia, una pieza de XML perfectamente escrita que utiliza string concat se actualiza para cumplir un nuevo requisito, y el código de concat de cadena es demasiado frágil.

Siempre que las alternativas fueran la serialización de XML y XmlDocument, podría ver el argumento de simplicidad a favor de string concat. Sin embargo, desde XDocument et. al., simplemente no hay razón para usar string concat para construir XML nunca más. Consulte la respuesta de Sander para la mejor forma de escribir XML.

Otra ventaja de XDocument es que XML es en realidad un estándar bastante complejo, y la mayoría de los programadores simplemente no lo entienden. Actualmente estoy tratando con una persona que me envía "XML", completa con valores de atributo sin comillas, etiquetas de finalización faltantes, sensibilidad de mayúsculas y minúsculas incorrecta y escapado incorrecto. Pero como IE lo acepta (como HTML), ¡debe ser correcto! Suspiro ... De todos modos, el punto es que la concatenación de cadenas te permite escribir cualquier cosa, pero XDocument forzará el cumplimiento de estándares XML.

Answer 10

Escribí una entrada de blog en 2006 moaning about XML generated by string concatenation; el punto simple es que si un documento XML no puede validar (problemas de codificación, espacios de nombres, etc.) no es XML y no se puede tratar como tal.

He visto múltiples problemas con documentos XML que se pueden atribuir directamente a la generación de documentos XML a mano mediante la concatenación de cadenas, y casi siempre en torno al uso correcto de la codificación.

Pregúntate esto; ¿Con qué conjunto de caracteres estoy codificando actualmente mi documento ('ascii7', 'ibm850', 'iso-8859-1', etc.)? ¿Qué sucederá si escribo un valor de cadena UTF-16 en un documento XML que se ha declarado manualmente como 'ibm850'?

Dada la riqueza de la compatibilidad con XML en .NET con XmlDocument y ahora especialmente con XDocument, no tendría que ser un argumento convincente para serio no el uso de estas bibliotecas sobre mi humilde opinión básica de concatenación de cadenas.

Answer 11

La razón principal es SECO: No repetir.

Si utiliza string concat para hacer XML, constantemente repetirá las funciones que mantienen su cadena como un documento XML válido. Toda la validación se repetirá o no estará presente. Es mejor confiar en una clase que está escrita con validación XML incluida.

Answer 12

wsanville, son actitudes como la suya por la que tenemos que pasar tantas horas refabricando un código terrible que es difícil de mantener e imposible de reutilizar.

"Para ir rápidamente del punto A al punto B". Y luego tienes que cambiar algo ...

No, gracias, no en mi equipo.

Answer 13

Quizás nunca ocurra, pero ¿qué pasa si su entorno cambia a XML 2.0 algún día? Su XML concatenado con cadenas puede o no ser válido en el nuevo entorno, pero es casi seguro que XDocument hará lo correcto.

De acuerdo, ese es un alcance, pero especialmente si su XML que no es totalmente compatible con los estándares no especifica una declaración de versión XML ... simplemente diciendo.