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.

Cuba en el Clásico Mundial de Pelota

Al parecer, aquí se pueden ver los juegos de Cuba en vivo! No lo he comprobado.

telerebelde.ambacuba.org

Clásico Mundial de Pelota (béisbol, baseball, o como quiera que le llamen)

Aquí se puede ver el clásico en VIVO! Por supuesto, sólo transmiten un juego a la vez. La resolución no es ideal, pero es gratis, y algo es algo.

Descripción del proceso de aprendizaje: de "Novato" a "Experto"

Level 0: I overcame obliviousness
I now realize there is something here to learn.

Level 1: I overcame intimidation
I feel I can learn this subject or skill. I know enough about it so that I am not intimidated by people who know more than me.

Level 2: I overcame incoherence
I no longer feel that I’m pretending or hand-waving. I feel reasonably competent to discuss or practice. What I say sounds like what I think I know.

Level 3: I overcame competence.
Now I feel productively self-critical, rather than complacently good enough. I want to take risks, invent, teach, and push myself. I want to be with other enthusiastic students.

Obtenido de http://www.codinghorror.com/blog/archives/001226.html, que a su vez lo extrajo de una "Google conference" de James Bach http://video.google.com/videoplay?docid=6852841264192883219

DDDD, un paso adelante

Distributed Domain Driven Design me está pareciendo la arquitectura más completa y realista. Tiene una respuesta (en forma de patrón) para cada aspecto, y no permite que la arquitectura implique una seria afectación de la eficiencia, como es el caso del DDD que he venido aplicando hasta ahora.

El fórum de discusión es muy activo, y Udi Dahan y Greg Young aclaran todas las dudas con muchísima seguridad y lógica.

Estoy entusiasmado con esta nueva opción. Este es mi resumen:

From Udi:

"The problem is thinking about the form as editing the underlying entity.

Think of the form as the way the user tells the system which task they wish to perform.

A command from the user.

Push that command down through your architecture."

"No manipulating domain objects directly on the client in a distributed system.

Changing data involves sending a command to a “service” (not SOA)."

"Even if you went to the server, right then and there, and got the most up to

date data, a second after the user looks at it - it's already stale.

Somebody else may have changed it - unless you're doing pessimistic locking."

"Just use Guids to identify your entities and you’re all set in terms of correlation – no need to wait for the server to give you an Id back."

Utilizar Expression para lograr AOP: primitivo pero interesante

Esta es una idea que me vino a la cabeza y que no tengo tiempo de desarrollar ahora. Y tampoco quisiera que se me olvidara.

La principal dificultad a la que se enfrentan los frameworks que ofrecen AOP es la intercepción de las llamadas a los métodos. (Por cierto, este framework luce prometedor: PostSharp)

¿Y si al escribir el código los desarrolladores utilizaran un método que recibe como parámetro un Expression, un Action o un Function, que sirva para aplicar aspectos?

Debo mirar con más profundidad.