Buenas prácticas aplicando MVVM: Introducción

Voy a escribir una serie de post donde no me quiero centrar demasiado en la explicación del patrón,  lo que quiero es compartir mis reflexiones sobre buenas prácticas utilizando el patrón, o por lo menos lo que yo considero que son buenas prácticas.

Estas buenas prácticas las he ido aprendiendo muchas veces de mis propios errores y aprendiendo de ellos,
y otras veces gracias a compañeros de trabajo con más experiencia que yo aplicando este patrón de diseño, con los que he tenido la oportunidad de trabajar y con los que he tenido charlas extendidas donde a veces se puede aprender más que en cualquier curso.


Algunos o muchos de vosotros no estaréis de acuerdo con alguna o todas las buenas prácticas que comparto con vosotros en esta serie de post y os animo a que dejéis comentarios con vuestras opiniones y así poder aprender unos de otros.

Objetivo y beneficios de MVVM

La buena práctica más básica y la que considero más importante es tener claro el objetivo del patrón.

El objetivo del patrón consiste en separar en 3 los conceptos que puede existir en la capa de presentación:
datos, lógica de presentación y la representación visual de los datos y acciones que podemos realizar como usuarios. Cada uno de los conceptos tiene un componente como responsable de llevarlo a cabo.

• Modelo, su responsabilidad es la de contener los datos de la aplicación.
• Vista, su responsabilidad la representación visual de los datos al usuario y de las acciones que el este puede realizar.
• ViewModel, su responsabilidad es la de contener la lógica de presentación y hace de intermediario entre la vista y el modelo. 

Parece algo muy básico para ser considerado una buena práctica pero a veces cuando nos metemos a desarrollar algo, por el motivo que sea puede que perdamos de vista los conceptos más básicos del patrón, que son las responsabilidades de cada componente. Echando un repaso a las responsabilidades de cada componente en ese momento puede aclararnos las ideas.

Si separamos responsabilidades vamos a obtener beneficios, para mi los más importantes son estos:

• Dividir el trabajo entre compañeros, donde antes de este patrón todo el desarrollo sobre una vista se hacia en la propia vista, en code behind, se hacia difícil el poder compartir el desarrollo de esta entre varias personas, con la separación de responsabilidades se hace mucho más fácil que por ejemplo un compañero se encargue de la vista y otro del view model
• Cambios en la forma de representar la información no implican reescribir lógica, lo que supone mucha mayor agilidad para cambiar la interfaz de usuario y menos probabilidad de errores funcionales por cambios en la interfaz de usuario.
• Vamos a poder tener tener test unitarios para nuestra la lógica que se encuentra en los view models.

Uso de framework sí o no

Cuando vamos a empezar un desarrollo, en algún momento aparece la duda de que framework utilizar. En este punto mi intención no es evaluar los diferentes frameworks porque solo he utilizado un par de ellos y no estoy en posición de decir cual me parece mejor de todos los que hay y porque. Yo he utilizado casi siempre en MVVM Light y muy poco Prism, también estuve en una empresa donde nos desarrollamos nuestro propio framework.

Mi opinión es que no hay ninguna opción mejor que otra a priori pero si tienes claro lo que necesitas y lo que te puede ofrecer cada solución, suele ser rápida la elección.

Para cosas muy sencillas donde simplemente necesitas un ViewModel base que se encargue de la lógica de notificación de cambios, un RelayCommand o DelegateCommand que te de soporte al tema de comandos y poco más porque no vas a tener que navegar entre páginas, ni comunicación entre view models o con servicios de mensajería ni nada parecido, posiblemente no necesites un framework y si encima estas empezando a utilizar este patrón te va a servir para sentar unas buenas bases de conocimiento sobre todo lo que engloba a MVVM.

Resumen

Hemos visto una introducción a buenas prácticas de MVVM, hemos visto el objetivo del patrón y las responsabilidades de cada componente y un consejo de cuando utilizar un framework.

Este primer post de la seríe ha sido un poco teórico pero en los próximos veremos ejemplos más concretos con código.

Libros Relacionados

MVVM Unleashed

• Amazon.com
• Amazon.co.uk

Advanced MVVM

• Amazon.com
• Amazon.es
• Amazon.co.uk