MVVM

Patrones arquitectónicos

En el mundo de desarrollo de software, un patrón arquitectónico define la estructura fundamental de un sistema: nos indica sus subsistemas que lo forman definiendo concretamente sus responsabilidades y los acompaña de reglas que definen la comunicación entre ellos.

¿Qué es MVVM?

MVVM es un patrón arquitectónico de software de reciente creado (por ahí del 2005) por un par de arquitectos (Ken Cooper y Ted Peters) de software en Microsoft. Su nombre proviene de los componentes o subsistemas que lo forman: Model - View - ViewModel

Al ser un patrón arquitectónico, define los siguientes componentes, de ellos, algunos tal vez de suenen conocidos, como la vista y el modelo, en realidad lo nuevo está en el ViewModel.

Model (Modelo)

En MVVM el modelo encapsula la lógica y/o el acceso a datos de la aplicación. En ella podemos ver acceso a una base de datos con SQLite, una conexión a un web service, algoritmos y validaciones relacionadas con la lógica del negocio que se busca resolver con la aplicación.

Es importante señalar que el modelo debe ser independiente de la plataforma en la que se esté ejecutando la aplicación (a esto se le conoce como platform agnostic), es decir, no debe preocuparse por cómo los datos son presentados al usuario. El hacerlo así además de cumplir con lo establecido por MVVM, además maximiza la posibilidad de poder reusar el código de este componente.

ViewModel

En el componente de los ViewModels actúa como un intermediario entre la vista y el modelo, en su labor de intermediario encapsula la lógica de presentación de la información en la vista. Entre sus responsabilidades están tres principales:

• La de controlar las interacciones que suceden en la vista y enlazarlas a acciones en el modelo. Por ejemplo, cuando se da click en un botón, se desliza algún control o se cambia el valor en textbox, esto a través de commands. O la de llevar datos que un usuario ingresó en la interfaz de la aplicación para ser respaldados o procesados en el modelo. Suele suceder que presenta una capa de validación intermedia, como validar la longitud de texto o el número máximo de algún valor que se pueda ingresar en la aplicación.

• La de recuperar y “transformar” la información producida (u obtenida) en el modelo y la enlazarla con la vista. Parte de estas transformaciones pueden incluir:
  • La conversión de tipos de dato a algunos que se representen mejor en la vista, los tipos “bool” a palabras como “sí” o “no”
  • El juntar o separar datos, por ejemplo, un tipo DateTime en fecha y hora, o nombre apellido paterno y apellido materno en una sola propiedad
  • El converir errores de validación o excepciones a algo que la vista pueda consumir y mostrar en la pantalla
• Notificar a la vista de los cambios que ocurran en él y en sus propiedades.

La implementación perfecta del componente de MVVM no contiene código relacionado con la vista, solamente expone propiedades que deben ser consumidos por esta para funcionar, idealmente los viewmodels también deben ser platform agnostic.

View (Vista)

Podemos definir la vista como lo que el usuario final ve de nuestra aplicación y a través de lo que interactúa con ella. Las responsabilidades de la vista incluyen definir la estructura, apariencia y comportamiento de los datos en la “pantalla”.

La como ya se mencionó antes, la vista se relaciona con los viewmodels, esta interacción se realiza a través de data bindings o enlaces de datos. Estos enlaces de datos establecen un canal de comunicación entre estas dos capas. La vista le “informa” al viewmodel de los cambios o eventos que ocurren en ella y el viewmodel le informa cuando ha ocurrido algún cambio en el modelo.

Idealmente la cantidad de código en este componente se limita a código relacionado con sus responsabilidades, ninguna lógica o validación relacionada con los datos debe estar incluida aquí. Sin embargo, hay ocasiones en las que es necesario usar código como cuando se requiere algún tipo de animaciones o alguna otra modificación a la vista no relacionadas con la lógica de la app.

Está de más señalar que la vista si depende al 100% de la plataforma, no puedes implementar la vista de Android en iOS… a menos que estés usando Xamarin.Forms, pero esa es otra historia.

Relaciones con patrones de diseño

Hay ciertas cosas como la navegación, acceso a alertas, sensores u otros elementos de la plataforma sobre la que está corriendo nuestra aplicación que tal vez no sean sencillas de incluir en una arquitectura como MVVM, sin embargo, podemos auxiliarnos de patrones de diseño. Uno de los más recurridos es el de la inyección de dependencias, el Factory o Singleton, y muchos más (Si quieres saber un poco más de alguno deja un comentario acá abajo).

Beneficios

El decidir usar este patrón en el desarrollo de nuestra app tiene algunos beneficios:

• Como la posibilidad de compartir una gran cantidad de código entre diversas plataformas.
• La separación de preocupaciones y con ello la facilidad de dividir el trabajo en diversas etapas o equipos de trabajo.
• Mayor facilidad a la hora de hacer pruebas unitarias.

Contras

Sin embargo, también puede traer algunas complicaciones, en especial para algunos tipos de aplicaciones, entre sus contras tenemos:

• Requiere una gran infraestructura de código para ser implementado o en otras palabras, requiere de mucho código para crear las clases encargadas de establecer la conexión Vista-ViewModel.
• Complica la depuración de errores que suceden en la vista

Estos son contras que se acentúan en especial si estamos desarrollando una aplicación pequeña, ya que a veces las complicaciones de implementar este patrón en apps pequeñas o muy sencillas sobrepasan el hacerlo de manera tradicional

Lugares en donde se usa

El patrón MVVM se puede implementar en casi cualquier desarrollo de software, pero hay entornos y plataformas que lo hacen el patrón por excelencia para desarrollar sobre ellas, entre ellas las plataformas de Windows: Windows 8, Windows phone y ahora Windows 10. También Xamarin.Forms (da click aquí si quieres ver un caso práctico de una app y Angujar JS lo toman como un patrón aceptado y usado para desarrollar sobre ellos.

Conclusión

En realidad, no existe una policía de MVVM que te vaya a detener si no implementas rigurosamente el patrón, ya dependerá de ti y las necesidades de tu aplicación qué tan rigurosamente lo implementas. También recuerda que MVVM no es la solución a todos los problemas, hay casos en los que no valdrá la pena usarse y otros en los que sí.