c# - mvc - MVVM: diferencia entre el modelo y el modelo de vista

mvvm xamarin

Question

Nunca antes había usado MVVM, así que probablemente me esté perdiendo algo obvio. Cuando creo una nueva aplicación Panorama, ya hay una carpeta ViewModel que contiene ItemViewModel y MainViewModel.

Pensé que "MainViewModel.cs" es el archivo que organiza el panorama. Sin embargo, dentro de MainViewModel, tiene esta línea:

 public MainViewModel()
{
this.Items = new ObservableCollection<ItemViewModel>();
}

ItemViewModel no tiene interacción con el panorama. Estos son los entonces instanciados así:

this.Items.Add(new ItemViewModel()
{ LineOne = "first line", LineTwo = "second line", LineThree = "third line" });

¿Por qué no es ItemViewModel solo un ''Modelo''? Implementa INotifyPropertyChanged, pero ¿para qué? Pensé que el ObservableCollection en MainViewModel sería suficiente para notificar cualquier cambio, como se demuestra aquí

Gracias

Answer 1

El ObservableCollection notificará cuándo se agregan o eliminan elementos de la lista, pero INotifyPropertyChanged en el ItemViewModel es necesario si desea que las notificaciones sucedan cuando cambian esas propiedades.

Answer 2

Es el mismo concepto general detrás de todas las arquitecturas MV [x], aunque MVC, MVP o MVVM:

• Usted tiene el modelo por un lado, que es básicamente una abstracción de software de su dominio comercial. No sabe ni le importan las cosas relacionadas con la interfaz de usuario (como, por ejemplo, en su caso ''notificar a la UI sobre cambios''). Implementa la lógica comercial y eso es todo.
• Por otro lado, tiene la interfaz de usuario, con necesidades específicas tanto en términos técnicos (por ejemplo, "WPF quiere vincularse a una ObservableCollection ") como en términos de presentación del usuario (p. Ej., Sobre diferentes ordenamientos de fechas o diferentes signos decimales en diferentes idiomas) .
• Para hacer frente a esto y poder separar claramente estos requisitos en una arquitectura limpia, necesita el [x], en su caso el ViewModel. Es la única capa dentro del software que conoce tanto la interfaz de usuario como el modelo. De lo contrario, no debería haber conexión alguna entre los dos.

En su ejemplo simple, esto podría parecer excesivo, pero un software comercial normal tendrá docenas o incluso cientos de trillizos MV [x], y no tendría forma de mantener una arquitectura limpia sin esto.

Para responder a su pregunta: lo que tiene en su ejemplo es solo un poco de código de cableado para configurar la arquitectura descrita.

HTH! Thomas

Answer 3

La diferencia es bastante simple.

El modelo posee lógica comercial.
El modelo de vista contiene lógica de presentación y, además, tiene una forma que se adapta a las vistas.

En su caso, el modelo de vista implementa INotifyPropertyChanged . Esa es pura lógica de presentación.

Model no es responsable de notificar a una IU en particular que algo ha cambiado, es responsable de transferir facturas, calcular los salarios, etc.

Algunas veces (cuando el modelo es simple) esta abstracción no es necesaria.

Algunas citas de wiki :

Modelo : como en el patrón clásico de MVC, el modelo se refiere a cualquiera
(a) un modelo de objetos que representa el contenido del estado real (un enfoque orientado a objetos), o
(b) la capa de acceso a datos que representa ese contenido (un enfoque centrado en los datos).

ViewModel : el ViewModel es un "Modelo de la Vista", lo que significa que es una abstracción de la Vista que también sirve para el enlace de datos entre la Vista y el Modelo. Se podría ver como un aspecto especializado de lo que sería un Controlador (en el patrón MVC) que actúa como un encuadernador / convertidor de datos que cambia la información del Modelo en información de Vista y pasa los comandos de la Vista al Modelo. ViewModel expone propiedades públicas, comandos y abstracciones. El ViewModel se ha comparado con un estado conceptual de los datos en oposición al estado real de los datos en el Modelo .