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
Cuanta razón!!!!
Excelente post…
Comparto sobre todo lo que dices de los scripts de construcción de Ant o MsBuild… que infierno. ¡Si es algo puramente procedural!, primero haz estos luego aquello si se da tal condicion esto otro… sería mucho más lógico hacer los scripts de construcción en, por ejemplo, PowerShell que en XML. En cuanto crecen un poco son ilegibles…
Un saludo.
Muy buen artículo.
Esto es justamente lo que pasa por pensar que XML (o AJAX, o LINQ, o la ‘buzzword’ de moda) es El Remedio A Todos Los Males Del Mundo Mundial, y que hemos de utilizar esa ‘tecnología’ sí o sí, por encima de todas las cosas.
Me recuerda bastante, ya que mencionas los antipatrones, al de «Cargocultismo» que no hace mucho comentaba Ian Marteens ( http://commanet.blogspot.com ). Por cierto el otro antipatrón que menciona, el de «El pollo de Skinner», aunque no existe en la versión «oficial» de la lista de Antipatrones (o yo no lo he visto), bien merecería que lo incorporasen, porque tiene más razón que un santo…
Saludos
Gracias Rodrigo! Pensé que justamente en el punto de Ant no iba a lograr apoyo pero parece que me equivoqué. Es totalmente cierto que sería más lógico en PowerShell, por ejemplo.
PabloNetrix, totalmente de acuerdo, le haz dado en el clavo con buscar balas de plata. Y el enlaze que me pasaste es muy bueno, no conocía a ese tipo pero esa serie que ha comenzado es muy buena. La de los pollos de Skinner yo ya la conocia con otro nombre y Deming da otros ejemplo muy buenos que se parecen a este de los pollos. El «Cargocultismo» se ve todo el tiempo y a veces no es culpa de los desarrolladores… mira, todavia hay gente haciendo aplicaciones con DataSets porque los libros y tutoriales los usaban!
Saludos muchachos y gracias por el aporte.
jejeje Lucas, como que poco apoyo por NAnt ??? si todavía hoy sufro tratando de interpretar verdaderas poesias escritas para tratar de compilar 2 clases.
Más allá de la usabilidad del XML (algun día te contaré el mal que acarreó en mi historia profesional la primera versión del MSXML) lo que comentas es muy cierto, mucha gente conoce una nueva tecnología/moda/etc y a partir de ahi, esa tecnología/moda/etc sirve para solucionar todos los problemas, groso error que nos da trabajo pero que nos quita años de vida 😛
Saludos
Muy bueno!!
Pero por sobre todo como comentan lo de Nant, que es una locura que para tareas que se podrian encarar de forma más sencilla tener que enrrollarse tanto =( a veces pienso debo ser muy tonto(seguramente)o que la gente la complica mucho, porque parece que la idea es mostrar uhh como la complico que groso soy..
Saludos
KS
¿Solo conoces DOM para leer XML?
las bases de datos relacionales esta obsoletas pero son lo unico que funciona hasta hora. Siempre he visto con buenos ojos todo intento por reemplazarlas y parece que «Document-oriented database» va por buen camino. Es algo parecido a lo que planteas en tu primer ejemplo.
Mi, si bien conozco otras cosas como sax, solo he usado dom. La idea no es si se leanta con dom o se recorre con sax o con lo que sea, la idea de este post es mostrar al que está mal.
Si no te parece ahora a lo mejor dentro de algun tiempo si lo veas mal pero quienes lo han hecho así lo han creido una genialidad y en realidad no lo es.
Que las bases de datos orientadas a objetos y xml pueden tener caracteristicas comunes es cierto pero de ahí a meter un xml en una tabla es incorrecto.
Fantastico articulo, en el pasado sufri mucho la xmlmania, lo que hay que ser es practicos.
Hablas de la doble transformación? He visto cosas peores, con codigo embebido en xml.. de arquitecturas y entornos propietarios..
PingBack desde HardBit » Modificar archivos XML con Inno Setup
Estoy de acuerdo en todo menos en lo de Ant.
¿Habéis programado algo con ant?
¿Habéis creado tareas ant alguna vez?
¿Habéis anidado vuestras propias tareas e utilizado macros?
No me refiero a hacer el build.xml sino a programar una tarea java para Ant…
Gracias a la estructura xml que tiene, hacer una tarea ant es FACILISIMO y POTENTISIMO, la rautilización de tareas también, el anidamiento etc…
Yo tengo el ant integrado en nuestras aplicaciones para la empresa y ya os digo yo que gracias al xml y a la forma de asignar los datos y xml anidados (realmente se cargan objetos en tiempo real) nos ha dado una potencia infinita
Hay que meterse un poco más a fondo para criticar el uso de xml de ant….