Conoce más sobre MVVM para el desarrollo de aplicaciones en iOS

Con el advenimiento de la programación Orientada a Objetos  y metodologías cada vez más sofisticadas para la construcción de Interfaces de Usuario ( UI ), se sintió la necesidad de desarrollar patrones que permitieran “ mantener los niveles separados ”. En la base de estos enfoques está el objetivo de permitir que el modelo , la «lógica» y la interfaz  de usuario vivan su propia vida y de manera completamente independiente entre sí. Tenga cuidado de no tergiversar el concepto ya que estamos hablando de independencia funcional y no de aplicación: significa que si cambiara, por ejemplo, el modelo por uno «equivalente» desde el punto de vista de los tiposla aplicación, si está bien estructurada, debería seguir funcionando sin pestañear. Este enfoque es seguido por el ya consolidado MVC , Model View Controller , ahora imprescindible en las aplicaciones empresariales (Java JSF y ASP .NET).

El tema de esta breve introducción es el patrón que lleva el nombre de MVVM , Model View ViewModel , cada vez más utilizado en el desarrollo de aplicaciones WPF , Silverlight , Windows Phone y Windows 8 ya que, en particular entre las dos últimas plataformas mencionadas, permite , utilizando una implementación específica, para «reutilizar» gran parte del código.

Ya se ha dicho que MVVM en sí mismo no es una biblioteca ni un ayudante, sino un patrón o, si lo prefiere, un enfoque para el desarrollo de aplicaciones. Aunque si quieres saber más te recomendamos Apple Coding Academy. Fue introducido por primera vez por John Gossman durante el desarrollo de WPF y es un descendiente directo del patrón Presentation Model  de Martin Fowler .

Consiste en separar los aspectos de nuestra aplicación en tres componentes:

• Modelo
• Vista
• Ver modelo

permitiéndonos evitar mezclar el código que proporciona la lógica con el que maneja la interfaz de usuario.

Los componentes

El modelo  representa el punto de acceso a los datos. Esta es una o más clases que leen datos de la base de datos o de un servicio web de cualquier tipo.

La Vista  representa la vista de la aplicación, la interfaz gráfica que mostrará los datos.

El ViewModel  es el punto de encuentro entre la Vista y el Modelo: los datos recibidos de este último son procesados ​​para ser presentados y pasados ​​a la Vista.

El punto de apoyo del funcionamiento de este patrón es la creación de un componente, el ViewModel de hecho, que representa toda la información y los comportamientos de la Vista correspondiente. De hecho, la Vista se limita a mostrar gráficamente lo expuesto por el ViewModel, a reflejar en él sus cambios de estado oa activar sus comportamientos.

¿Cómo interactúan los distintos niveles?

1. El usuario interactúa con la Vista .
2. El cambio de estado se comunica a ViewModel ( Binding ), o se activa un método a través de Command .
3. En respuesta a un cambio de estado o activación de método, ViewModel «hace algo» en el modelo  y actualiza su estado.
4. El nuevo estado del ViewModel  se refleja en la Vista .

Cabe subrayar que el ViewModel mantiene en su propio estado no solo la información recuperada a través del Model, sino también el estado actual de la visualización: esto le permite estar completamente desacoplado de la View. Además, el proceso paso a paso descrito anteriormente resulta ser «de dos vías», es decir, funciona en ambas direcciones.

Binding e INotifyPropertyChanged en MVVM Light Toolkit

Al ser un patrón, MVVM no necesita ninguna biblioteca en particular para implementarse: ni hay ninguna lista para usar que pueda hacernos la vida más fácil. El más famoso es sin duda >MVVM Light Toolkit.

Resumamos los mecanismos:

• Todas las interacciones con la interfaz de usuario son manejadas por ViewModel, que actúa como el contexto de datos de la vista y las propiedades expuestas por ViewModel están vinculadas a la interfaz de usuario a través de Binding .
• Al implementar la interfaz INotifyPropertyChanged , cada vez que cambia una propiedad de ViewModel, la interfaz se actualiza al nuevo valor y viceversa.

En particular:

• ViewModel es básicamente una clase que implementa la interfaz INotifyPropertyChanged  .
• Para notificar a un control que la propiedad de enlace ha cambiado, se desencadena un evento. Para hacernos la vida más fácil, Light Toolkit nos proporciona el método RaisePropertyChanged(..)  para no crear un evento personalizado cada cierto tiempo.
• Es necesario recordar que el ViewModel no sabe nada sobre el funcionamiento del Model . Lo importante es que se asigna al tipo de datos.
• Enlace con nombre explícito y modo TwoWay para permitir la interacción bidireccional entre View y ViewModel .
• El modelo  no sabe nada sobre la vista y cómo se representarán los datos.

En la práctica: ICommand porque no solo vivimos de datos

La aplicación es generalmente y sobre todo interacción con el usuario: en el modelo clásico este aspecto se representa mediante eventos. Sin embargo, estos últimos hacen poco MVVM ya que nos obligarían a mezclar un poco las cosas y escribir algo de código en   el código subyacente de View . Solo para evitar esto, los Comandos vienen a nuestro rescate .

Cada interacción es un comando ( función normal ) que se puede expresar a través        de Binding gracias a la propiedad Command expuesta por todos los controles que requieren interacción. El comando a invocar debe ser de tipo ICommand  y declarado en ViewModel.