Introducción a MVVM con Xamarin Forms

Yhorby Matias
Xamarin Latino
Published in
5 min readJun 20, 2017

--

Para hablar sobre MVVM debemos tener claro que son los patrones de diseño y quizas mas de uno se lo esté preguntando en estos momentos, por lo que lo vamos a definir a continuación.

¿Qué son los patrones de diseño?

Los patrones de diseño son soluciones para problemas típicos y recurrentes que nos podemos encontrar a la hora de desarrollar una aplicación. Aunque nuestra aplicación sea única, tendrá partes comunes con otras aplicaciones: acceso a datos, creación de objetos, operaciones entre sistemas etc. En lugar de reinventar la rueda, podemos solucionar problemas utilizando algún patrón, ya que son soluciones probadas y documentadas por multitud de programadores.

¿Por qué usar patrones de diseño?

Si queremos desarrollar aplicaciones robustas y fáciles de mantener, debemos cumplir ciertas “reglas”. Lo pongo entre comillas porque aunque estas reglas de diseño son recomendables (muy recomendables), no son obligatorios. Siempre podemos decidir no aplicar. Aunque si no lo hacemos, hay que ser conscientes de la razón de no aplicarlas y de sus consecuencias. Los patrones de diseño nos ayudan a cumplir muchos de estos principios o reglas de diseño. Programación SOLID, DRY, control de cohesión y acoplamiento o reutilización de código son algunos de los beneficios que podemos conseguir al utilizar patrones.

¿Cuando nace MVVM?

En el año 2004, un grupo de desarrollo de Microsoft trabajaba en un proyecto denominado “Avalon”, mejor conocido por su nombre definitivo WPF (Windows Presentation Foundation). El propósito de dicho proyecto era permitir el desarrollo de aplicaciones de escritorio más completas y con un aspecto visual mucho más logrado y complejo de lo que era posible con Windows Forms. Al año siguiente John Gossman (miembro del equipo de desarrollo de “Avalon”), en un artículo de la MSDN, mostraba al público el patrón MVVM. En el artículo, MVVM se presenta como una variación del patrón MVC ajustado a “WPF” y a su sistema de enlace a datos, aunque realmente es una adaptación del patrón “presentation model” creado por el mítico Martin Fowler.

Elementos del patrón MVVM

La finalidad principal del patrón MVVM (Modelo Vista Vista-Modelo) es tratar de desacoplar lo más que se pueda la interfaz de usuario de la lógica de la aplicación. Veamos a grandes rasgos sus partes principales:

El modelo (Model)

Representa la capa de datos y/o la lógica de negocio, también denominado como el objeto del dominio. El modelo contiene la información, pero nunca las acciones o servicios que la manipulan. En ningún caso tiene dependencia alguna con la vista.

La vista (View)

La misión de la vista es representar la información a través de los elementos visuales que la componen. Las vistas en MVVM son activas, contienen comportamientos, eventos y enlaces a datos que, en cierta manera, necesitan tener conocimiento del modelo subyacente. En Xamarin Forms podemos crear nuestras interfaces a través de código C# o XAML.

Modelo de vista (ViewModel)

El ViewModel (modelo de vista) es un actor intermediario entre el modelo y la vista, contiene toda la lógica de presentación y se comporta como una abstracción de la interfaz. La comunicación entre la vista y el viewmodel se realiza por medio los enlaces de datos (binders).

ViewModel contiene el estado de la vista y se comunica con ella a través de Data Binding, Commands y Notificaciones gracias a la interfaz INotifyPropertyChanged

usando INotifyPropertyChanged en el ViewModel

Bindings

Como hemos dicho la forma de comunicación entre el ViewModel y la Vista es a través de Data Binding y Commands. Esta comunicación es posible gracias a la interfaz INotifyPropertyChanged.

implementacion de Command ViewModel

RECORDEMOS

Una interfaz contiene las definiciones de un grupo de funcionalidades relacionadas que una clase o una estructura pueden implementar.

Como podemos ver lo que realmente hace esta interfaz, es lanzar un evento cada vez que una propiedad cambia.

Nuestra vista estará suscrita a estos eventos de cambio y eso es lo que llamamos Data Binding o Binding.

Data Binding en la vista (View)

Un Binding relaciona 2 propiedades entre sí de forma que se mantengan sincronizadas. En nuestro caso bindieamos Oneway.

One Way Binding

Los cambios que realicemos en la propiedad de nuestro ViewModel se propagan a la propiedades de nuestros controles en la vista.

Two Way Binding

Las dos propiedades enlazadas tienen la capacidad de propagar los cambios. Es decir, si cambiamos la propiedad de nuestro ViewModel, se informará a la vista del cambio.

Relación entre Vista y ViewModel

Es muy importante dejar claro que nuestro ViewModel no tenga conocimiento alguno de la Vista al que va a ser bindeado. Si tenemos claro este concepto durante el desarrollo, el mismo ViewModel puede servirnos para la vista de iPad, la de iPhone, la de Mac, la de UWP, etc. El contrario no aplica, la vista tiene la libertad de estar altamente acoplada a un ViewModel en concreto.

Este Patrón nos da ciertas ventajas:

• Separar el desarrollo de la interfaz de usuario del resto del código. Es decir, podemos tener un equipo de diseño trabajando en la interfaz de usuario y a los programadores haciendo el resto de la aplicación.

• La lógica de presentación puede ser probada con pruebas unitarias (unit testing) al estar desacoplada de nuestras vistas.

• Muy útil cuando estamos desarrollando aplicaciones multiplataforma, ya que tanto la lógica de negocio, como la lógica de presentación es común a todas las plataformas.

Keep Coding!

--

--

Azure Solutions Architect || Azure DevOps || Azure Administrator || GCP || AWS || 🧙‍♂️ available for contracts