My kemenworld…

To mock or not to mock…

El momento en que una factory o template no tiene sentido

Posted by kementeus en enero 14, 2008

Desde hace buen tiempo soy defensor del desarrollo de software mediante Factories, a tal manera de implementar en base a las Microsoft Factories nuestras propias factories en la oficina. Bueno, hace unos días me topé con el caso muy especial de un cliente, donde ninguna factory, generador de código o hasta metodología podría ayudarme.

Mi cliente en especial necesitaba rápidamente trasladar un aplicación hecha en un “dialecto” extraño de alguna Table base storage engine (Fox, DBase y sus temibles amigos, ya saben que no soy muy fanático de ellos). El detalle es que este cliente en especial necesitaba a toda costa mantener su horrible “muy especial” esquema actual de juguete “base de datos” y para un contrato en específico necesitaba “portarlo” a una verdadera base de datos, así que simplemente tomó a su herramienta “DBA” de confianza y transformó cada una de las tablas DBF a una tabla dentro de un esquema de una base de datos de SQL Server 2005, interesante no?.

La cuestión es que mi trabajo en la oficina era crear una “simple” aplicación en ASP.net que se encargara de manejar datos de ese monstruo esquema. Bien, como estándar usamos WCSF v2.0, una Factory hecha en casa para crear ciertas CRUD screens, y por supuesto otra factory hecha en casa para crear el repositorio en base a NHibernate. Error garrafal, si revisaran las tablas creo que el diseñador del esquema original (el de DBF) nunca leyó a nuestro amigo Codd, recuerdan las formas normales? bueno creo que estas estaban en la -1 forma normal de Codd, lo bonito es que no podia tocar el esquema verdad :S.

Bueno, terminé escribiendo los archivos de mapeo en HBM a manitas (algo que acostumbro a hacer de todos modos) usando componentes, ya que dentro de una misma tabla de más de 100 atributos (si, para aquellos que no se acuerdan de la jerga, un atributo es una columna en jerga SQL), y dentro de esa misma tabla estaban los padres, hijos y abuelos de la “entidad”, o sea, es como si metieran dentro de una misma tabla gigantesca el encabezado de factura, el detalle de factura y los productos que son usados en el detalle de factura, se imaginan? bueno aún veo esa tabla en mis pesadillas.

Ya que los padres e hijos de la entidad estaban mapeados como componentes en nhibernate hacer una simple consulta de listar a todos los “padres” era algo dificil ya que usando criterias se dificultaba como no se imaginan. A final de cuentas fue cuando comprendí “ahh en estos casos es cuando vale la pena tirar a la borda todo lo aprendido y mejor hacer las rutinas de persistencia a manitas”.

Puff, bueno, necesitaba desahogarme de alguna manera, espero terminar esto pronto y porfavor, NORMALIZEN LAS COSAS POR EL AMOR DE DIOS!!!

Saludos!

2 comentarios to “El momento en que una factory o template no tiene sentido”

  1. Ricardo said

    Que onda kementeus (le iba a dar strike a otro nombre pero mejor no ja) Imagino los dolores de cabeza con el que te topaste, Yo soy de la progra orientada a los datos y trato de pulir y dejar lo mas normalizado posible haciendo excepciones por cuestiones de performance. En cierta charla (creo que fue la de SOA del ultimo msdn del 2007) hablaste de como muchos programamos sobre datos y no sobre servicios y me llamo particularmente la atencion pues yo estoy en esa rama ja, pero con todo lo que han platicado de servicios, factories, interfaces, patrones, etc. me doy cuenta que bien puedo cambiar para bien ja! Recuerdo que mencionaste un ejemplo y no es por nada pero le pegaste al clavo conmigo, una aplicacion que lleve el control de productos y de la noche a la mañana quiere meter a los vendedores obviamente tendria que alterar los datos y agregar una columna IdVendedor pero ese dia dijiste en vez de utilizar un servicio, en este ejemplo tan sencillo que tocaste cual seria la mejor practica para el caso?

    Saludos!

    PD. Haber si llega Marlon a la charla de Hibernate apuesto a que metera las manos al fuego por el Entity Framework y LINQ

  2. kementeus said

    No entiendo lo de la Entity Framework (de la cual soy defensor también). De hecho, LINQ no tiene nada que ver con NHibernate, en todo caso sería con HQL (lenguaje que es muy inferior a LINQ) y la Entity tiene sus grandes pro ante NHibernate (uno de ellos documentación). Inclusive se puede subsistir con la mezcla de ambos, te cuento que ya existen drivers de NHibernate para consultar entidades usando LINQ.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: