2010-09-29 29 views
8

Nunca antes había usado MVVM, por lo que probablemente me esté perdiendo algo obvio. Cuando creo una nueva aplicación Panorama, ya hay una carpeta ViewModel que contiene ItemViewModel y MainViewModel.MVVM - Diferencia entre el modelo y el modelo de vista

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

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

El ItemViewModel no tiene interacción con el panorama. Estas son las siguientes instanciadas 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é? Yo he pensado que el ObservableCollection en MainViewModel sería suficiente para notificar cualquier cambio, como demonstrated here

gracias

Respuesta

5

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

+0

Entonces, por ejemplo, si el aspecto de cambio de propiedad era irrelevante para el ItemViewModel, ¿tendría sentido 'relegar' eso simplemente a 'Modelo'? – Brap

+1

No creo que gane mucho haciendo eso. Déjalo como un modelo de vista y solo llama al controlador de eventos para esos elementos que necesites. De esta forma, está preparado para la eventualidad de que necesite implementar la notificación. – Robaticus

11

La diferencia es bastante simple.

El modelo tiene lógica de negocios.
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 - ver el modelo implementa INotifyPropertyChanged. Esa es pura lógica de presentación.

modelo no es responsable de notificar a una interfaz de usuario particular que algo ha cambiado, es responsable de transferir las facturas, el cálculo de los salarios etc.

veces (cuando el modelo es simple) esta abstracción no es necesario sin embargo.


Algunos wiki citas:

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

modelo de vista: el modelo de vista es un “modelo de la vista” lo que significa que es una abstracción de la Ver que también sirve de unión entre la vista y el modelo de datos. 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 ha sido comparado con un estado conceptual de los datos en comparación con el estado real de los datos en el Modelo.

10

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

  • Usted tiene el modelo, por un lado, que es básicamente una abstracción de software de su dominio del negocio. No sabe y no 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.
  • En el otro lado tiene la interfaz de usuario, con necesidades específicas tanto en términos técnicos (por ejemplo, 'WPF quiere vincular a un ObservableCollection') como en términos de presentación del usuario (por ejemplo, sobre diferentes ordenamientos de fechas o diferentes signos decimales en idiomas diferentes).
  • 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 el ejemplo sencillo, esto podría parecer una exageración, pero un software comercial normal tendrá docenas o incluso cientos de [x] trillizos tales MV, y que no tendría forma de mantener una arquitectura limpia y 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

Cuestiones relacionadas