Otra pregunta de MVVM ... ¿Es correcto mi entendimiento?

Question

Disculpe si se trata de un duplicado, aunque no es tanto "¿Qué es MVVM?" Sino "¿Es este MVVM?", He leído bastante y creo que tengo una comprensión básica de lo que es , Tengo mi propio "liner", como tal, sobre cómo lo interpreto, pero quiero asegurarme de que sea correcto antes de que lo arrastre firmemente en mi cabeza,

Esencialmente; El Modelo es información pura: sin métodos, hay un modelo de vista por modelo, contiene una referencia al modelo, realiza todos los cambios en los datos de los modelos y, finalmente, la vista contendrá una (o más) referencia (es) de ViewModel y formato. & muestra los datos proporcionados por el ViewModel.

(No después de enlaces a tutoriales, blogs, etc, sólo un sí o no con ajustes va a estar bien, ya que voy a tener que volver a leer todo lo nuevo de todos modos, si no :))

Answer 1

No completamente, al menos, no como lo definiría por completo.

El modelo no tiene que ser puro. El modelo es la parte de su aplicación que es completamente específica del dominio y no tiene información relacionada con la presentación.

Esto generalmente incluirá todos los datos específicos de dominio, pero también métodos potencialmente puros de lógica de negocios, acceso a datos, etc. Cualquier cosa específica para la lógica y procesos de negocios, y no parte de la "pantalla" es parte del modelo.

Además, aunque "un modelo de vista por modelo" es la forma más común de trabajar, hay ocasiones en que puede exponer una clase "modelo" a través de múltiples modelos de vista. Esto puede ser útil, por ejemplo, si intenta exponer solo parte de un modelo a su diseñador, ya que le permite crear una clase ViewModel más pequeña. ViewModel adapta el modelo para trabajar con la Vista: si no se requiere todo el Modelo, este adaptador se puede hacer más pequeño (y más fácilmente comprobable, mantenible, etc.) trabajando solo con la parte requerida.

Personalmente, prefiero pensar en términos de "un ViewModel per View", ya que ViewModel puede adaptar uno o más modelos para que funcionen correctamente con una View determinada, pero aun así, a veces es útil cambiar un ViewModel dentro de la misma Vista para cambiar el contenido.

Answer 2

Esencialmente, sí . Prácticamente, no realmente. La mejor práctica es siempre reducir las dependencias y dividir sus responsabilidades entre las clases en una base 1: 1, pero encontrará situaciones IRL donde no es tan fácil ser un purista de MVC.

Creo que la mejor actitud es hacer lo mejor posible, luego documentar el resto. No sudar demasiado la pureza.

Answer 3

Eso está bastante cerca. Excepto que no es correcto decir que el Modelo es solo información pura. Puede y debe contener métodos para realizar los diversos casos de uso en su contra.

Answer 4

Cerrar, pero no del todo. Aquí hay algunos puntos que son diferentes a los suyos:

1. Los modelos pueden tener métodos en ellos. No son solo datos. Pueden tener métodos como "recuperar", "almacenar", etc. Código de lógica de negocios. Ver agnóstico

2. No hay restricciones en la cantidad de ViewModels que contienen una referencia al modelo. ViewModels encapsula el comportamiento del nivel de vista, por lo que puede tener muchos conjuntos diferentes de comportamiento para el mismo modelo. Por ejemplo, un ViewModel puede ser una transformación de solo lectura de un elemento de modelo. Otro podría proporcionar la validación del formulario de lectura/escritura en el mismo artículo modelo.

3. Puede haber más de un ViewModel por vista, según el comportamiento que desee. Por ejemplo, puede incluir el comportamiento de "contenido premium" con un modelo de ViewModel y el comportamiento de "contenido libre" con otro ViewModel, pero mantener la misma vista.

Answer 5

Aquí hay mucha información excelente, y creo que la mayoría de estas respuestas son correctas. No creo que haya ninguna definición específica, ni hay una autoridad específica sobre este asunto. Incluso Microsoft no tiene una definición clara sobre esto.

El único elemento que agregaría que no está en el nombre de MVVM, pero es común a todas las implementaciones de MVVM con las que estoy familiarizado. Este es un sistema de Mensajes o Notificación, que parece estar siempre vinculado como una plataforma para ViewModel. La mensajería simplemente notifica a los Modelos de Vista cuando cambian las cosas que pueden afectar a otros. Una buena implementación de esto en mente permite que View View y Views sean agnósticos sobre cosas a las que no se vinculan directamente mediante el uso de mensajes de notificación genéricos.

El beneficio de todo el patrón, en mi opinión, es hacer que la aplicación tenga piezas intercambiables y modulares con la menor dependencia de tipo posible.

Esta es una parte realmente perdida en mi mente, ya que proporciona los mismos beneficios/funciones que obtienes de una lógica de controlador separada en el patrón MVC.

Answer 6

Su comprensión es incorrecta. Puede tener varios modelos y todos ellos pueden tener sus propias vistas y luego ser parte de un único modelo de vista. Ejemplo: Tiene los modelos: Producto, Cliente Cada uno de ellos tiene su propia Vista representada como un Control personalizado Y usted tiene un ViewModel que combina todos sus modelos y finalmente en la ventana de su aplicación combina todos sus puntos de vista que hablar con sus modelos a través de su ViewModel

Answer 7

Piénselo de esta manera. El modelo es tu sistema, la carne y verduras de lo que hace el sistema. Las únicas consideraciones que tiene es cómo hacer su trabajo, no cómo se usará. Expone eventos, atributos y métodos definidos a nivel de sistema, pero no tiene ningún concepto de lo que presionará sus botones (¡o si tiene botones!). No intenta formatear los datos a un formato más fácil de usar, formatea sus datos de una manera amigable con los modelos.

---

El modelo de vista es el UX (experiencia del usuario). Define cómo vas a usar el sistema. Define (a través de los comandos y atributos públicos) el acceso orientado al usuario en el sistema. Es el puente que usará el usuario para ingresar al sistema. Se une a los eventos del modelo y, a través de sus comandos, proporcionará acceso a la funcionalidad de los modelos.

Debe manejar la validación, (¿es esa edad una edad razonable?) Recuperar datos, convertir y almacenar en caché los registros mientras se muestran. Entonces, por ejemplo, está mirando un registro de paciente, el modelo de vista obtiene los datos del modelo y los almacena en la memoria caché internamente, y luego los publica en la vista. ¿Qué sucede si el modelo anuncia una actualización de esa información? ¿Desechar los datos en caché? ¿Qué pasa si lo has editado? Todo depende de usted, y este comportamiento debe definirse en el modelo de vista.

El modelo de vista es un "contrato" de qué funcionalidad y datos están expuestos al usuario (a través de la vista). El modelo de vista no tiene ningún concepto de CÓMO se va a mostrar o interactuar. Los comandos deben nombrarse a nivel funcional, como RefreshList, NOT MouseClickHandler.

---

Finalmente, la Vista. Esto es simplemente una representación visible de lo que está en el modelo de vista. Botones, menús, etc. se unen a los comandos. Los campos se unen a los atributos y se actualizarán automáticamente a través de la magia de enlace.

Si alguna vez te ves haciendo: "text1.text = value" lo estás haciendo mal. Si alguna vez te encuentras escribiendo un controlador de comando que dice "my.ViewModel.SomeCommand", lo estás haciendo mal.