español - mvvm xamarin ejemplo

Conceptos básicos de MVVM: ¿qué debería hacer un ViewModel? (5)

Al tratar de entender los conceptos de MVVM, ya he leído varios blogs y he visto algunos proyectos.

Por lo que entiendo, una Vista es tonta, solo sabe cómo presentar algo que se le pasa.

Los modelos son solo los datos simples, y un ViewModel es algo que actúa como un relleno entre los dos, que debería obtener información del Modelo y pasarla a la Vista , y la Vista debería saber cómo presentarla. O al revés, si la información en la Vista cambia, debe pasar el cambio al Modelo .

Pero todavía no tengo idea de cómo aplicar el concepto. ¿Alguien puede explicar un escenario muy simple para que pueda captar el concepto? Ya he analizado varios proyectos, pero aún no tiene mucho sentido, así que si alguien pudiera escribirlo en inglés, sería agradable.

Gracias :)

Construir un ViewModel que presenta una fachada consistente sobre el Modelo subyacente puede ser mucho más complejo de lo que parece. Este artículo sobre la construcción de objetos ViewModel demuestra cómo crear un ViewModel e ilustra algunos de los problemas que probablemente encuentre, junto con lo que parecen ser soluciones razonables. Cuando lo leí, me faltaba la sección sobre el tratamiento de las colecciones, pero todavía tengo algunos puntos interesantes.

Lo escribí como "inglés sencillo", como puedo pensar en esta serie sobre MVVM . En particular, este diagrama es probablemente la explicación más simple y breve.

Dicho esto, básicamente, el "modelo" son sus reglas de datos o de negocios. Realmente no debería saber cómo o dónde va a usarse, y especialmente no qué tecnología va a usarlo. El "modelo" es el núcleo de la aplicación, y no debería preocuparse si la aplicación es WPF, Silverlight, Windows Forms, ASP.NET, etc., es solo "en sí mismo" en una forma pura.

La "Vista" es la parte que es completamente específica de la tecnología. En MVVM, idealmente, la Vista debería ser casi 100% XAML, ya que proporciona grandes ganancias para la flexibilidad.

Sin embargo, es necesario que haya algo que traduzca la información del Modelo a alguna forma en la que pueda utilizarse con la tecnología en cuestión: aquí es donde entra en juego ViewModel. Por ejemplo, esto a menudo "envuelve" las clases de modelo en un "Modelo de Vista" para esa información específica que incluye Comandos (para ejecutar lógica), implementa INotifyPropertyChanged (para soporte de enlace de datos), etc. Eso es - es el puente que hace que el Modelo utilizable por la Vista.

Me gusta pensar de esta manera:

Las vistas, como dices, son tontas. Josh Smith, escritor del artículo seminal ya menudo vinculado de MSDN sobre MVVM, ha dicho que las vistas son "la ropa que usan los datos". Las vistas en realidad nunca contienen datos ni los manipulan directamente, solo están vinculados a las propiedades y comandos de sus viewmodels.

Los modelos son objetos que modelan el dominio de su aplicación , como en los objetos comerciales. ¿Tu aplicación es una tienda de música? Quizás los objetos de tu modelo sean artistas, álbumes y canciones. ¿Tu aplicación es un navegador de organigramas? Quizás sus objetos modelo serán gerentes y empleados. Estos objetos modelo no están relacionados con ningún tipo de representación visual, y ni siquiera están directamente relacionados con la aplicación en la que los está insertando: los objetos de su modelo deberían tener sentido por sí solos como una familia de objetos que representan algún tipo de objeto. de dominio. La capa de modelo también suele incluir elementos como los descriptores de acceso del servicio.

Esto nos lleva a Viewmodels. ¿Qué son? Son objetos que modelan una aplicación GUI , lo que significa que proporcionan datos y funcionalidades para que los utilicen las vistas. Son lo que define la estructura y el comportamiento de la aplicación real que está construyendo. Para los objetos modelo, el dominio es el dominio que elija (tienda de música, navegador de organigramas, etc.), pero para el modelo de vista, el dominio es una aplicación gráfica. Sus viewmodels van a encapsular el comportamiento y los datos de todo lo que hace su aplicación. Van a exponer objetos y listas como propiedades, así como cosas como Comandos. Un comando es simplemente un comportamiento (en su forma más simple, una llamada a un método) envuelto en un objeto que lo transporta: esta idea es importante porque las vistas son impulsadas por el enlace de datos, que asocia los controles visuales a los objetos. En MVVM, no le da a un botón un método de control Click, lo vincula a un objeto de comando (servido desde una propiedad en un modelo de vista) que contiene la funcionalidad que desea ejecutar cuando hace clic en él.

Para mí, los bits más confusos fueron los siguientes:

Aunque los viewmodels son modelos de una aplicación gráfica, no hacen referencia directa ni usan conceptos visuales. Por ejemplo, no desea referencias a los controles de Windows en su ViewModels: esas cosas van en la vista. ViewModels simplemente expone datos y comportamientos a controles u otros objetos que se unirán a ellos. Por ejemplo, ¿tiene una vista con un ListBox en ella? Es casi seguro que tu modelo de vista tendrá algún tipo de colección. ¿Tu vista tiene botones? Es casi seguro que tu modelo de vista tendrá algunos comandos.
Hay algunos tipos de objetos que podrían considerarse "viewmodels". El tipo más simple de viewmodel para entender es aquel que representa directamente un control o una pantalla en una relación 1: 1, como en "la pantalla XYZ tiene un cuadro de texto, un cuadro de lista y tres botones, por lo que el modelo necesita una cadena, una colección, y tres comandos ". Otro tipo de objeto que encaja en la capa del modelo de vista es un envoltorio alrededor de un objeto modelo que le da un comportamiento y lo hace más útil para una vista: aquí es donde entra en los conceptos de capas de modelo de vista "gruesas" y "finas". Una capa de modelo de vista "delgada" es un conjunto de modelos de vista que exponen los objetos de su modelo directamente a las vistas, lo que significa que las vistas terminan vinculadas directamente a las propiedades en los objetos modelo. Esto puede funcionar para cosas como vistas simples de solo lectura, pero ¿qué ocurre si desea tener un comportamiento asociado con cada objeto? No quiere eso en el modelo, porque el modelo no está relacionado con la aplicación, solo está relacionado con su dominio. Puede colocarlo en un objeto que envuelve su objeto modelo y ofrece datos y comportamientos más vinculantes. Este objeto envoltorio también se considera un modelo de vista, y al tener como resultado una capa de modelo de vista "más gruesa", donde tus vistas nunca terminan vinculadas directamente a nada en una clase de modelo. Las colecciones contendrán viewmodels que ajustarán los modelos en lugar de solo contener los modelos.

El agujero del conejo es más profundo: hay muchos modismos para descubrir como ValueConverters que mantienen MVVM funcionando, y hay mucho que aplicar cuando comienzas a pensar en cosas como Blendability, testing y cómo pasar datos en tu aplicación y asegurarte de que cada modelo de vista tiene acceso al comportamiento que necesita (aquí es donde entra la inyección de dependencia), pero es de esperar que lo anterior sea un buen comienzo. La clave es pensar en sus imágenes, su dominio y la estructura y el comportamiento de su aplicación real como tres cosas diferentes.

Una gran introducción a MVVM se puede encontrar en el video de Jason Dolinger here . Mantuve el video conmigo durante bastante tiempo cuando comencé, es realmente útil.

Utilizando este artículo increíblemente útil como fuente, aquí hay un resumen de View , ViewModel y Model .

Ver:

La vista es un elemento visual, como una ventana, página, control de usuario o plantilla de datos. La vista define los controles contenidos en la vista y su diseño y estilo visual.
La vista hace referencia al modelo de vista a través de su propiedad DataContext . Los controles en la vista son datos vinculados a las propiedades y comandos expuestos por el modelo de vista.
La vista puede personalizar el comportamiento de enlace de datos entre la vista y el modelo de vista. Por ejemplo, la vista puede usar convertidores de valores para formatear los datos que se mostrarán en la interfaz de usuario, o puede usar reglas de validación para proporcionar validación adicional de datos de entrada al usuario.
La vista define y maneja el comportamiento visual de la interfaz de usuario, como animaciones o transiciones que se pueden desencadenar a partir de un cambio de estado en el modelo de vista o mediante la interacción del usuario con la interfaz de usuario.
El código subyacente de la vista puede definir la lógica de UI para implementar un comportamiento visual que es difícil de expresar en XAML o que requiere referencias directas a los controles de IU específicos definidos en la vista.

NOTA:
Debido a que el modelo de vista no debe tener un conocimiento explícito de los elementos visuales específicos en la vista, el código para manipular mediante programación elementos visuales dentro de la vista debe residir en el código subyacente de la vista o estar encapsulado en un comportamiento.

Ver modelo:

El modelo de vista es una clase no visual y no se deriva de ninguna clase base de WPF o Silverlight. Encapsula la lógica de presentación requerida para admitir un caso de uso o una tarea de usuario en la aplicación. El modelo de vista es verificable independientemente de la vista y el modelo.
El modelo de vista normalmente no hace referencia directamente a la vista. Implementa propiedades y comandos a los que la vista puede enlazar datos. Notifica la vista de cualquier cambio de estado mediante eventos de notificación de cambio a través de las interfaces INotifyPropertyChanged e INotifyCollectionChanged .
El modelo de vista coordina la interacción de la vista con el modelo. Puede convertir o manipular datos para que la vista los pueda consumir fácilmente y puede implementar propiedades adicionales que pueden no estar presentes en el modelo. También puede implementar la validación de datos a través de las interfaces IDataErrorInfo o INotifyDataErrorInfo .
El modelo de vista puede definir estados lógicos que la vista puede representar visualmente para el usuario.

NOTA:
Cualquier cosa que sea importante para el comportamiento lógico de la aplicación debe ir al modelo de vista. El código para recuperar o manipular elementos de datos que se mostrarán en la vista a través del enlace de datos debe residir en el modelo de vista.

Modelo:

Las clases de modelo son clases no visuales que encapsulan los datos de la aplicación y la lógica de negocios. Son responsables de administrar los datos de la aplicación y de garantizar su coherencia y validez encapsulando las reglas comerciales requeridas y la lógica de validación de datos.
Las clases de modelo no hacen referencia directamente a la vista o ver clases de modelo y no dependen de cómo se implementan.
Las clases de modelo suelen proporcionar eventos de notificación de cambio de propiedad y de recopilación a través de las interfaces INotifyPropertyChanged e INotifyCollectionChanged . Esto les permite vincular datos fácilmente en la vista. Las clases de modelo que representan colecciones de objetos normalmente se derivan de la clase ObservableCollection<T> .
Las clases de modelo suelen proporcionar validación de datos e informes de errores a través de las interfaces IDataErrorInfo o INotifyDataErrorInfo .
Las clases de modelo generalmente se usan junto con un servicio o repositorio que encapsula el acceso a los datos y el almacenamiento en caché.