El XML es un gran invento pero sinceramente prefiero rodearme de monos con navajas que de desarrolladores con xml. Desde la primera vez que tuve contacto con el Extensible Markup Language hasta el dia de hoy he visto una cantidad de estupideces sorprendentes gracias al mal uso, y al sobre uso de este lenguaje. Voy a ir comentando de a uno los casos reales en que pude comprobar como la fórmula (XML*Inconciencia) da por resultado un verdadero desastre económico.
1.- XMLs a la Dase de datos. Un grupo que desarrollaba un producto de Record Management System para una verdadera multinacional de tecnología concluyó que el modelo relacional, con varios años de existencia y desarrollo, no era lo suficientemente bueno para ellos porque no les daba la suficiente "flexibilidad" que su capilla sixtina necesitaba por lo que decidieron... atención a esta!... crear una tabla con solo dos campos a saber: entityID int not null y, data text. Obviamente en el campo data, del tipo "text", va un enorme y amorfo xml que contendrá los datos que ahora, gracias a esta genialidad, serán libres de toma la forma que quieran.
Como las consultas sobre estos datos se complicaron un poquito se desarrolló toda una libreria para facilitar las busquedas pero funcionaba de la siguiente manera: por cada registro levanto el xml en memoria con DOM y mediante xpath compruebo si es lo que busco o no. Todavia no he visto como resolvieron los outer left joins y las agrupaciones pero sospecho que ya lo tienen en la bolsa.
Esto mismo lo vi muchas veces en muchos lugares así que no es una excepción.
2.- Una alternativa al paso de parámetros. En una migración de un producto grandioso desde Visual Basic 6 a VB.Net, el nuevo equipo decidió que el paso de parámetros entre métodos podía hacerse mucho mejor si todos los datos necesarios se fueran compartiendo en un xml de modo que cada método guardase o añadiese información de contexto (una especie de patrón Context pero "más flexible") a este xml. Así que todos los métodos recibian un solo parámetro del tipo XmlDocument y extraian aquello que les así falta, agregaban más datos y modificaban otros. Una especie de todos los antipatrones juntos: que encapsulamiento ni que ocho cuartos!
Bueno, más allá de que cada desarrollador le agregaba sus datos (y banderas también!) al xml y que modificaba los que habian puesto los otros desarrolladores, el problema fue la performance. Procesador al 100% el 100% del tiempo. Otro problemita se daba cuando un desarrollador nuevo invocaba un método... ya sabia que parametro recibia pero ¿que deia contener el xml? a mirar el código señores.
Pero ueno, de acá a 7 u 8 años, con los nuevos equipos, este producto tendrá un desempeño aceptable.
3.- La doble transformación. Un producto de eLearning se construyó con lo que en esa empresa alguien llamó "la arquitectura de doble transformación", y funcionaba así: ante una petición del usuario se invocaba a un componente que gracias a un XML determinaba que consultas debia tirarle a la base de datos y luego convertia todos esos resultados en un gran XML el cual pasaba por dos "transformaciones", dos XSLTs, el primero hacia operaciones sobre los datos y luego el segundo transformaba (creaba) la UI o lo que obtenia el usuario. De esta manera si mañana salia un nuevo requerimiento para exportar esos datos a .pdf, excel o a cualquier cosa solo se debia tocar el XSLT de la segunda transformación, mientras que lo demas permanecia igual.
¿Alguien puede imaginar lo que habia que hacer para depurar el código JavaScript que se habia generado con un XSLT?
De locos!
4.- El super app.config. Es tan fácil leer desde el app.config, o web.config, que todo lo que alguien no quiere hardcodear lo pone en el app.config. Incluso hasta recursos como los strngs en lugar de ponerlos en archivos de recursos van a parar a los archivos de configuración. Parece que me estoy equivocando, después de todo, no hay motivo por el que no se puedas poner string en estos archivos pero un equipo de trabajo del box de al dado tiene un web.config de casi 3 MB que me resulta sospechoso.
5.- (N)Ant. Escribir scripts con xml como Ant es una burrada. No tiene sentido implementar un leguaje script con XML y solo se justifica por el echo de que es fácil leerlo y nos evitamos la tarea de crear los analizadores léxico y sintáctico sino que solo tenemos que levantarlo con DOM.
Lucas Ontivero