lunes, 28 de septiembre de 2015

El Patrón Model - View - ViewModel ( MVVM )

Este año Google IO introduce un nuevo framework que parece impresionante para los desarrolladores de Android ,y que permite la "unión" de las vista a los campos en un 
objeto arbitrario. Cuando un campo se actualiza, el framework se da cuenta y la vista se actualiza automáticamente.

Este sistema es muy potente, y nos permitirá utilizar un modelo de desarrollo que se ha utilizado en el mundo de Windows durante algún tiempo llamado Model-View-ViewModel (MVVM). 
Antes de saltar a cualquier código, es importante entender los conceptos básicos de esta arquitectura, y la forma en que usted y su aplicación puede beneficiarse.

El patron Model - View - ViewModel fue concebido por John Gossman allá por el año 2005 en un post de su blob titulado "Introduction to Model/View/ViewModel pattern for building WPF apps"(http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx), siendo este una adaptación del patrón Presentation Model (http://martinfowler.com/eaaDev/PresentationModel.html) propuesto por Martin Fowlers para tecnologías .NET como XAML (como se conoce ahora al conjunto de herramientas para desarrollar en Windows 8), WPF y Silverlight. 

Este patrón junto a otros mas conocidos como MVC o MVP tiene por objetivo simplificar las tareas de desarrollo y mantenimiento del software escrito con estos a través de la división de ocupaciones, por lo cual alguien que ya haya trabajado previamente con alguno de los patrones previamente mencionados, le parecerá bastante familiar MVVM.

El patrón MVVM consta de tres partes:

a) Modelo - Representa la lógica empresarial
b) View - Lo que muestra el contenido
c) ViewModel - El objeto que une los dos puntos anteriores juntos

Model
El modelo, dentro de MVVM es el encargado de representar el modelo del negocio, proveyendo de esta manera la base necesaria para la manipulación de los datos de la aplicación, además parte del modelo se lo puede usar como clases POCO (Plain Old CLR Objects) para poder usarlas con Entity Framework Code First o algún otro ORM. Cabe resaltar que en el modelo, no debería de existir ninguna lógica de negocio o código que afecte a como se visualizan sus datos en pantalla.

View
La vista es la parte encargada de la parte visual de nuestra aplicación, no teniéndose que ocupar en ningún momento en el manejo de datos. En MVVM la vista tiene un rol activo, esto significa que en algún momento la vista recibirá o manejara algún evento (Clic en un botón, alguna tecla presionada, etc.) y tendrá que comunicarse con el modelo, para poder cumplir el requerimiento. 

ViewModel
El ViewModel (modelo de vista en español) es el encargado de ser la capa intermedia entre el modelo y la vista, procesando todas las peticiones que tenga la vista hacia el modelo, además de tener que ocuparse de manejar las reglas del negocio, la comunicación con aplicaciones externas o consumir datos desde alguna fuente (Bases de Datos, Web Services, Sensores, etc.). Para la comunicación entre el View y el ViewModel, utilizamos los enlaces de datos que nos permiten tener un código bastante limpio (Bindings http://msdn.microsoft.com/en-us/library/ms752347.aspx)


Observaciones
Trabajando con este patrón y migrando cientos de líneas de código Espagueti al patrón, he visto algunas practicas o concejos que pueden ser de bastante utilidad al menos al momento de comenzar a usar el patrón.
- El Code-Behind no tiene que existir: He escuchado bastante de eso por todo ello, y le cuento que es un tanto falso, para entender mejor como funciona el code-behind dentro del patrón MVVM, hay que pensarlo como si fuere el patrón MVC, donde la vista este escrita en HTML y el JavaScript que maneja todo lo referente a la vista(cambiar un color, redimensionar un control, etc.); ciertamente el Code-Behind hay que usarlo con cautela, pero a la vez prescindir por completo de el puede llevarnos demasiado tiempo, por regla, si algo que nos puede tomar un par de minutos con Code-Behind, nos toma horas sin el, entonces estamos yendo por mal camino.
- La vista debe ser 100% desacoplable de ViewModel: Esto al igual que el punto anterior hay que pensar primero en la dificultad que realizar esto conlleva, por que ciertamente no es a función principal del patrón, si es un aditamento, si es que es posible implementarlo en un lapso de tiempo corto y sin tener que crear una mayor estructura para que se lleve a cabo.
- No es necesario usar un Framework para MVVM: Esto es completamente cierto, ya que usando un par de clases escritas por nosotros o por terceros podemos tener nuestro proyecto con MVVM al 100%.
- MVVM es solo para aplicaciones grandes: Muy falso, MVVM funciona perfectamente bien para proyectos grandes y pequeños, inclusive por las características de una Aplicacion Android , Silverlight o XAML el desarrollo de toda aplicación es mas simple usando el patrón. En todo caso, al igual que el punto 2 el tiempo y la complejidad nos dirán si estamos aplicando de manera correcta el patrón, ya que perder horas montando la infraestructura para un proyecto que no requiere mas de unos minutos, no es lo correcto.

Es un tema para profundizar, pero el primer paso en entender la arquitectura, para luego trabajar con el Framework de DataBinding .

1 comentario:

  1. Buen artículo, tengo la creencia que el patron MVVM es utilizado para aquellas aplicaciones que se utilizan para datos de entrada y salida(lectura y escritura), mientras que el patron MVP es solo para entrada(lectura) de datos.

    ResponderEliminar