Wednesday, April 22, 2009

Revisando Composite Application Block (Prism)

Después de descartar dedicarle tiempo a Caliburn, le echo un vistazo a Prism. El vistazo es rápido porque no necesito mucho tiempo para ver cosas que no me gustaría ver en mi aplicación.

- Me parece demasiado complejo. Over-architected sería la palabra en inglés. Se parece demasiado al MVP del Composite Web Application Block. Es una complejidad que sufrí una vez y que evitaré siempre que esté en mis manos.
- ¿Un HelloWorld con 2 proyectos, 4 clases y 3 XAML? Sólo eso es una mala señal, aunque por sí mismo no signifique nada.
- Al igual que Caliburn, crea demasiadas abstracciones nuevas encima de WPF. Esto implica mayor curva de aprendizaje y mayor probabilidad de perder el tiempo invertido.
- También se utilizan string mágicos para referenciar elementos importantes de la aplicación, como las "regiones".
- La comunicación entre "módulos" es muy compleja.

El código publicado en codeplex no se corresponde con la última versión.

Conclusión

Seguramente, al igual que Caliburn, Prism implementa mucha funcionalidad, pero el precio de utilizarla me parece demasiado alto: curva de aprendizaje, cantidad de abstracciones por encima de WPF, complejidad impuesta a mi aplicación.

Revisando Caliburn

Estoy revisando Caliburn y
no me ha gustado lo que he visto. Hago un resumen muy rápido e incompleto.

Sólo estoy revisando los ejemplos y lo que veo es:

- Demasiado e incorrecto uso de atributos. Preview, Rescue, etc contienen lógica de ejecución. Me parece muy poco intuitivo y alejado del modelo tradicional espeficar esos aspectos mediante atributos.
- Con los atributos, se pierde todo el chequeo estático de tipos, utilizando para casi todo strings mágicos.
- Demasiada lógica en los XAML. Por ejemplo, se enlazan comandos, acciones, etc, indicando en el propio XAML, mediante una sintaxis inventada, a qué elemento de la vista se le va a asignar el resultado de una operación realizada en un comando o en el Presentador. El compilador tampoco detecta errores aquí.
- Demasiadas abstracciones adicionales por encima de WPF, lo que aumenta la curva de aprendizaje y el peligro de aprender algo que no será útil en otros entornos.

En mi opinión, esto se aleja del ideal:

- Mantener todo lo posible el chequeo estático de tipos!
- Toda la lógica está en los ViewModel.
- Ninguna lógica en el XAML. En el XAML sólo debe hacerse DataBinds contra las propiedades del ViewModel.
- Los XAML de la aplicación deberían ser la mayoría DataTemplates, uno por ViewModel.

Conclusión

Quizás Caliburn ofrezca muchas funcionalidades ya implementadas, pero utilizarlo:

- Me obligaría a aprender todo un modelo nuevo que se aleja demasiado de M-V-P y de WPF.
- EL framework te dirije a una aplicación sin chequeo estático de tipos, y muy parecida a un código espaghetti enlazado mediante strings mágicos.