Eligiendo un patron WorkWith

Hace unos meses, teníamos un  proyecto a realizar,  que por su tamaño  era bueno para hacer una evaluación del estado de los patrones que implementan el Trabajar con. 
De los que hay en la comunidad, los que conozco son:
Es muy bueno tener muchas opciones y poder optar por la que mejor se adapta a cada proyecto. 

La evaluación que hicimos fue en el mes de Enero, con la versión Ev2 aun no liberada,  la implementación de una aplicación de unas 10 tablas, con todos estos patterns para poder comparar cual se adaptaba mejor a lo que necesitábamos. 

Las cosas que evaluamos fueron:
De la herramienta de pattern:
  • Documentación
  • Soporte
  • Metodología de desarrollo
  • Costo
De la aplicación terminada
  • Usabilidad
  • Estética de la aplicación standard
  • Facilidad de desarrollo
  • NO evaluábamos performance, no era critico en esta aplicacion. 
No voy a entrar en un detalle de cada una de las evaluaciones, pues creo que solo aplica para nuestro proyecto. 

Usar el WorkWith que viene con GeneXus, sirve de prueba de concepto, para poder comprender la ventaja de la utilizacion de patrones y las mejoras en la productividad, siempre que se sepa usar. 
Al tiempo de usarlo, se le encuentran limitaciones y excepciones que no pueden ser desarrolladas correctamente con dicho patron, por lo que hay que salirse del mismo en varias oportunidades. 

El WorkWithPlus tiene muy buena documentación, el soporte es muy bueno. Nos permitió generar la totalidad de la aplicación con el Pattern. 
Tiene la ventaja que las pantallas pueden generarse en forma declarativa, de forma que todas las pantallas tienen una aspecto uniforme y fácil de modificar desde un único punto. 
Tiene herramientas de auditoria, seguridad, personalizacion de la estetica, etc. 

Con K2BTools, pudimos generar toda la aplicación, pero el uso y la practica nos resulto algo mas incómodo que el WorkWithPlus. La curva de aprendizaje es un poco mas pronunciada, aunque parece mas solido desde el punto de vista teórico, lo cual puede posicionarlo bien para el futuro. 
Hay herramientas adicionales de auditoria, manejo de seguridad. Despues de la prueba, no probamos el web designer en la prueba. 

Las pruebas que hicimos con PXTools, no terminaron bien, porque nos daba un error al generar con la versión no liberada de GeneXus Ev2. Para ser sinceros, la culpa del error era de la versión beta de GeneXus y no del pattern, pero nos impidió poder generar la aplicación para probarla en su momento. 
Dicho error ahora está solucionado. 


Cosas para el futuro. 

Incompatibilidades. 
Seria bueno que los pattern pudieran convivir en una misma KB. Por ejemplo, hoy es difícil tener el WorkWith y el WorkWithPlus en la misma KB, porque se pisan en funciones comunes. 

Patterns compartidos
Me gustaría que los patterns pudieran interactuar entre ellos. Por ejemplo, seria bueno tener un patron que generar una planilla excel, y que otros los patrones lo pudieran invocar. Se tiene lo mismo con funciones de auditoria, generación de PDF, funciones de seguridad, etc. Seria bueno que fueran compartidas por todos los patrones. 

Uso de nuevos objetos. 
Veo los patrones como ejemplos de las buenas practicas de proguramacion, con lo que me gustaria que todos usaran por ejemplo, data selectors para la seleccion de los workwith. De esta forma seria muchisimo mas faciles de extender, cuando por ejemplo tengo que agregar funcionalidad no standard al patron. 

Mejorar la interacción con GXServer. 
Hoy los objetos generados con patrones y GeneXus Server no se llevan bien. 
Si por error falta enviar un objeto en un COMMIT, se producen problemas que luego son difíciles de solucionar. Esto debería ser menos trabajoso para el desarrollador y se deberían brindar herramientas para enviar todos los objetos generados por el pattern al seleccionar una instancia, o GeneXus debería darse cuenta y avisar que no faltan objetos. 
No entiendo bien porque GXServer genera los objetos faltantes cuando se sube un instancia, pues esto provoca varios problemas, pero supongo que debe tener alguna explicación, que aun no entendí, pero es uno de los causantes de la mayoría de los problemas.   
Creo que hay oportunidades de mejora tanto del lado de GeneXus, como de los patrones, para que puedan trabajar mejor juntos. 

Luego de realizada la prueba, optamos por WorkWithPlus pues era el que nos brindaba mejores prestaciones y se ajustaba al presupuesto que teníamos para dicho proyecto. Aun seguimos aprendiendo a usarlo y adaptardolo a nuestras necesidades pero por ahora, cumple con las expectativas. 

Comentarios

  1. Muy bueno el Post. Se podria agregar en cosas para el futuro "Hermamientas de Conversion" tengo una Kb con WW de Gx y no hay una herramiennta para migrar a K2BTools.

    ResponderEliminar
  2. Siempre es bueno leer tus columnas Enrique. Nuestro equipo de desarrollo también eligió WorkWithPlus por la relación calidad/precio y hoy te diría que una de sus mejores características es el Soporte.

    Lo único que no entiendo es por qué GeneXus no lo ofrece por defecto.

    ResponderEliminar
    Respuestas
    1. Anonimo:
      Supongo que hay motivos comerciales por los cuales Genexus no lo ofrece con el Development Environment, pero estoy de acuerdo que seria una herramienta mas productiva y facil de usar si lo tuviera.

      Eliminar
  3. Hola!

    Muy bueno el Post! Quería comentarte que WorkWithPlus cuenta con una herramienta para migrar las instancias WW de GX a WWP en forma automática.

    Saludos,

    ResponderEliminar
    Respuestas
    1. Eugenia:

      Si, hay muchos criterios que quedaron afuera del analisis.

      El tener un migrador de instancias del WorkWith al WW+ , ayuda mucho para empezar, pero como es algo que se va a usar solo una vez, no lo considere un factor de gran peso. Pero colabora en hacer mas facil el arranque.

      Eliminar
  4. Muy buen post Enrique. Yo solo he usado WorkWith y me enfrenté a sus muchas limitaciones, comparto que sirve de prueba de concepto; solo pudimos utilizarlo de forma aceptable para algunos mantenimientos de tablas muy básicos. Este post me ha resultado muy útil e ilustrativo.

    ResponderEliminar
  5. Hicimos una aplicación para todo un core bancario solo para consultas con el WW+ la verdad como se eleva la abstración es muy importante, y hacer todo declarativo, y en performance la aplicación maneja millones de registros, muchas cosas de esto tuvimos evaluar más como generabamos nosotros y optimizabamos que el mismo pattern los soportará (Crear indices hacer filtros etc.) muy buena herramienta tienen razon deberían evaluar de integrarse a GENEXUS.

    ResponderEliminar
  6. Hola Enrique, muy bueno el post, respondo el porque hoy GeneXus Server aplica los patterns. Esto pasa porque los patterns al salvar generan objetos, estructuras, etc que luego son usados, si no son salvados podría llegar a fallar hasta el salvado del objeto que estas haciendo commit.

    Saludos

    ResponderEliminar
    Respuestas
    1. Gaston:
      Supongo que habran pensado bien ventajas y desventajas de aplicar los patterns. Desde mi punto de vista, ahora veo las desventajas, pues se dificulta mucho usar GXServer con Patterns, porque siempre se desincronizan. Supongo que mejorará la forma en que trabajan juntos dichas herramientas.

      La duda que me queda, es si yo tengo patron aplicado en mi KB, ya tengo todos los objetos generados en mi KB local. Es *probable*, que lo que quiera subir, sean exactamente los objetos que tengo en mi KB y no que vuelva a generar los objetos (que podrian tener diferencias con los mios).
      Como dije, no tengo la información de todos los patrones, ni experiencia de que necesita GeneXus para poder salvar, pero me gustaria tener la opcion que los patrones no se apliquen en GeneXus Server cuando se sube un objeto que tiene aplicado patterns.

      Eliminar
    2. Coincido con Enrique.

      En mi opinión, el approach de GXServer debería ser NO aplicar el pattern en el server y SI versionar tanto la instancia como los objetos generados. Ahí creo que se acaban los problemas.

      Eliminar
    3. @Guilleguy, mi opinion es igual a la tuya, pero no tengo la generalidad de los casos, como si la conoce Gaston.
      Desde mi punto de vista, seria bueno que fuera opcional aplicar o no el pattern en el server, de forma de poder evitar muchisimos problemas..

      Eliminar
  7. Hola, este post esta buenisimo, pero tengo una consulta que no la pude encontrar en ningun post, por que razones elegir pattern y por que no? te lo tiro por si te parece que vale la pena.
    Saludos.

    ResponderEliminar
    Respuestas
    1. Veronica:
      Supongo que tu pregunta apunta porque usar patterns o no.
      La ventaja de usar patrones en el desarrollo, ayuda a tener mayor productividad en el desarrollo y en el mantenimiento de la aplicacion. Se pueden generar pantallas web mas rapido y de mejor calidad que haciendolas a mano.

      Otra ventaja es que es mas facil que los programas cumplan con normas de programacion, estandar de codificacion, de controles de seguridad, de diseño grafico compatible, si se hacen generados por patrones.

      Como contra, se tiene que se generan muchos mas objetos que antes, haciendo que la KB crezca mas rapido en cantidad de objetos.

      Tambien se eleva el nivel de abstraccion, y algunos programadores tienen mas dificultad en entender que cambiando algo en una instancia del patron, se afecta a muchos programas o tambien entender que es lo que hay que cambiar para lograr el cambio deseado.

      A mi me parece muy bueno incorporar patrones en el desarrollo y desarrollar nuevos patrones a medida que los vaya necesitando, pues se logra mejorar la productividad.

      Eliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Codigo simple