Jounce, Parte 1: ¿Con qué motivo?

Traducción aproximada del artículo Jounce Part 1: Why? publicado en inglés por Jeremy Likness el 12 de octubre del 2010 en su blog C#er:Image.

 

En las siguientes semanas voy a publicar una serie de artículos explicando un proyecto de fuente abierta que acabo de lanzar llamado Jounce. Su proposito es suministrar guías sobre cómo crear aplicaciones modulares en Silverlight usando la infraestructura de extensibilidad administrada (MEF por sus siglas en inglés) y el patrón Modelo-Vista-Modelo de Vista (MVVM).

 

Inicios

He estado desarrollando aplicaciones de tipo empresarial en Silverlight desde finales de su segunda versión. Muchas de estas aplicaciones requerían alguna forma de extensibilidad con el fin de poder, de manera fácil, añadir módulos o pantallas. Hasta en su infraestructura se ocupa un grado de modularidad para poder reducir en el cliente el tiempo de transferencia y la memoria requerida de la aplicación, cargando partes adicionales de manera dinámica.

Por otra parte, luego de probar el patrón Modelo-Vista-Controlador (MVC) y experimentar con MVVM, rápidamente me di cuenta que el este último era ideal para mi trabajo. La experiencia de más de una década creando aplicaciones esenciales para el funcionamiento de empresas, me ha ayudado a desarrollar la práctica de organizarlas como soluciones de bajo acople que sean fáciles de probar y distribuir a grandes equipos de programadores. Probé con varios métodos propios, con Unity, y con otros patrones antes de descubrir que MEF es el que satisface la mayoría de mis necesidades al usar Silverlight.

Como resultado final, he estado usando un conjunto de patrones comunes en varias aplicaciones. Los desarrolladores estamos muy familiarizados con la utilidad que proveen las herramientas y macros. También entendemos que empeñarnos en reinventar algo que ya existe resulta en una pérdida de tiempo para nuestros clientes. Es por eso que tiendo a reusar clases base, interfases y otras estructuras clave en diferentes proyectos. He mantenido estas entidades útiles en una biblioteca separada que uso como base para nuevos proyectos y le sigo añadiendo componentes a medida que encuentro nuevas soluciones.

Hace poco empaqué la biblioteca y la publiqué bajo e nombre de Jounce. Es muy similar a varias otras bibliotecas de MVVM en el sentido de que provee servicios de mensajería y controladores para INotiryPropertyChanged. Sin embargo, es diferente por no intentar mantenerse separada de la capa de inversión de control en la que se basa. No dejo lugar a dudas de que Jounce depende directa y explícitamente de MEF.

 

¿Debería usar Jounce?

Desde hace tiempo ya que he querido compartirla, pero me lo ha impedido el hecho de que en realidad no necesitamos otra biblioteca más. Eso mismo me preguntaron cuando decidí que mis artículos y ejemplos en el blog no son lo suficientemente claros fuera del contexto de la biblioteca en la que se basan.

La respuesta a la pregunta es simple: no.

No es mi deseo el competir con las varias otras bibliotecas ya existentes y más maduras. Todas son excelentes. Así que entonces, ¿cuál es la razón para publicar Jounce? Mi intención no es tanto proveer una infraestructura que contenga la solución a todos los problemas, como más bien ofrecer una guía sobre las formas en las que MEF me ha ayudado a resolver los retos de usar MVVM en Silverlight. Su objetivo es muy específico y no trata de cubrir Silverlight y WPF y Windows Phone 7, o de ser independiente de la noción de contenedores de inyección de dependencias. Es un conjunto limitado de principios que he usado para resolver problemas en un ámbito específico.

La idea es que el lector puede descargar el código fuente y examinar a cabalidad esta biblioteca ultraliviana (con menos de mil líneas de código). La licencia para Jounce permite que sea usada tal y como está, pero se me hace que la mayoría van a tener necesidades específicas que van más allá de lo que cualquier paquete pueda ofrecer. Es por eso que los invito a modificar y personalizar el código cuanto lo deseen, usando las partes que son útiles y descartando las que no.

En comparación con Prism, Jounce es mucho más pequeño y con un enfoque más estrecho. La administración de regiones es implementada en unas pocas líneas de código y no es tan flexible como en Prism, pero yo nunca he necesitado todo ese poder adicional. Tampoco tiene el tipo de enlace de datos automático basado en convenciones de Caliburn y Caliburn.Micro, pero por usar un proceso de desarrollo enfocado hacia diseñadores, yo prefiero enlazar los datos de forma explícita y usar modelos de vista dedicados a la etapa de diseño.

En las partes donde Jounce se basa en otras bibliotecas he tratado de hacer mención a la fuente y proveer recursos para explorarlas más a fondo.

Estos son algunas de las pautas contenidas en Jounce:

 

  • El código en App.xaml.cs es distrayente e innecesario. Es preferible usar el IApplicationService que es más elegante.
  • El rastreo es importante aun cuando Silverlight no lo incluye de forma nativa.
  • Los comandos deben ser súper fáciles de conectar y usar cuándo y dónde sean  necesarios.
  • Debe permitirnos crear mensajes sobre la marcha y dejar que sean consumidos en cualquier parte de la aplicación (sin tener que lidiar con transferencias de datos al hilo de ejecución de la interfase gráfica).
  • Es un dolor tener reorganizar código que usa cadenas con los nombres de propiedades al disparar eventos de propiedad cambiada. Es mejor usar tipos verificados por el compilador.
  • Los modelos de vista deben sincronizarse con el estado visual, por lo que deben estar al tanto de los cambios en dicho estado y poder asignar estados visuales sin tener que referirse a la vista.
  • Etiquetar un modelo de vista debería ser simple y flexible.
  • Igual con las vistas.
  • No debería se tan engorroso el enlazar una vista a un modelo de vista. Debería ser posible decir que esta vista va con ese modelo de vista y ya.
  • Hay que admitirlo: los modelos de vista hablan entre sí. Así que hagamos fácil el que se puedan contactar.
  • Si navego a una vista, no debería tener que preocuparme de si la vista se encuentra en un archivo XAP cargado de forma dinámica.
  • La navegación no debería ser más que un evento simple, separado de detalles de implementación como el cambio de vistas, la transición visual y así por el estilo.
  • No debería tener que usar tres monitores para examinar la maraña de métodos y expresiones lambda relacionados con un grupo de operaciones asincrónicas que son disparadas de forma secuencial.

 

¿Por dónde empiezo?

El código fuente completo se encuentra disponible en Codeplex. Lo pueden descargar, compilar y empezar a usarlo. La biblioteca incluye un proyecto de web con una vista y modelo de vista. También tiene varios ejemplos simples que demuestran la navegación, regiones, cargado de XAPs y más. Tengo el plan de agregar otros más en la versión 1.0.

Para mí, la mayor ventaja de Jounce es la experiencia obtenida al usarlo. Todos los proyecto de ejemplo fueron creados en poco tiempo y con pocos o ningún problema que depurar. Yo pienso que ese es el objetivo ideal de una infraestructura o biblioteca: ser tan liviana como sea posible, fácil de usar y fácil de depurar cuando las cosas van mal. Jounce exhibe, en mi opinión, todas esas características.

En conclusión, Jounce no es la “siguiente biblioteca espectacular” que les estoy exhortando a descargar y usar. No es mi intención comenzar a publicar nuevas versiones cargadas de fabulosas nuevas funcionalidades… aunque si encuentro mejores formas de resolver un problema o se me ocurre una idea que es usada con frecuencia, es posible que la incluya en un futuro.

En los siguientes artículos voy a empezar a cubrir en detalle la funcionalidad de Jounce. Las mayoría de estos aspectos van a ser familiares parar los que siguen mi blog, pero esta vez las ideas están contenidas dentro de una infraestructura completa y no en pequeños ejemplos separados.

Sus comentarios y sugerencias son bienvenidos.

 

Jeremy Likness

 

Etiquetas asignadas:
 

Responder



Licencia de uso

El contenido de las traducciones está sujeto a los términos de protección de derechos de uso de los autores originales quienes han autorizado su publicación en este blog. Asegúrese de entender los terminos de la licencia de cada autor antes de usar tal contenido.

Mis propios artículos son publicados bajo los términos de la Licencia Reconocimiento-Compartir bajo la misma licencia 3.0 Estados Unidos de Creative Commons:

Creative Commons License
Blog de Maromas Digitales by Maromas Digitales, LLC is licensed under a Creative Commons Reconocimiento-Compartir bajo la misma licencia 3.0 Estados Unidos License.

License

The contents of all translated articles is subject to the copyright and licensing terms of the original authors and has been published here with their express permission. Verify the original author's licensing terms before using the contents of these articles.

My own articles are licensed under the Creative Commons Attribution-Share Alike 3.0 United States License:

Creative Commons License
Blog de Maromas Digitales by Maromas Digitales, LLC is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.