¿Cómo debería ser mi modelo?

Question

A medida que profundizo en MVVM y MVVM-light, reconocí que no existe una clase base proporcionada por MVVM-light para los modelos.

Pero desde mi entendimiento, las notificaciones de mensajes y aumento también podrían ocurrir en un modelo. Al menos en la comunicación entre modelos, encontraría que la mensajería sería muy útil.

Así que decidí derivar mi Modelo de ViewModelBase, aunque algunas de las propiedades (como las del tiempo de diseño) no se utilizarán.

Pero cuanto más estoy viendo esto, más creo que me he perdido algo. ¿Se considera una "mala práctica" derivar mis Modelos de ViewModelBase?

¿Y está bien utilizar la mensajería para la comunicación del modelo?

Answer 1

Deriva tus clases de modelos de vista de lo que quieras ... MVVM-light ofrece VieWModelBase para proporcionar una implementación de ICleanUp, que es buena para administrar el ciclo de vida de los objetos de ViewModel. Mi propia elección ha sido implementar todo el andamiaje para las notificaciones de cambio de propiedad en una clase base, y luego derivarlo para las clases modelo. Sobre las únicas sugerencias fuertes He respecto a las clases del modelo son:

1. Una vez que el tamaño no sirve para todos. Cómo almacena sus datos puede ser diferente de cómo interactúa con los datos, y los objetos ViewModel deben estar orientados a admitir la interacción, no el almacenamiento, y si necesita interactuar con los mismos datos (Modelo) de dos maneras muy diferentes, entonces diseñe dos diferentes ViewModels para soportar estas diferentes interacciones.
2. Utilice los atributos (a la System.ComponentModel) para anotar los modelos. Puede realizar gran parte de su trabajo de validación de esta manera, y la validación comentarios es responsabilidad de la capa de presentación (View + ViewModel), no del dominio problemático (es decir, el Modelo).

realmente buenas clases ViewModel también son lo suficientemente generalmente sin estado que pueden ser reciclados/reutilizados dentro de una sola interacción del usuario, de tal manera que grandes listas de datos se pueden virtualizar (WPF admite la virtualización) para guardar RAM.

Recuerde DRY (Do not Repeat Yourself), KISS (Keep It Simple, Stupid!) Y YAGNI (No vas a necesitarlo) - son los principios que debe tener en cuenta por encima de cualquier principio de diseño académicas. Literalmente he desperdiciado semanas en una aplicación WPF implementando patrones MVC/MVVM académicamente perfectos, solo para descubrir que detraeron de la comprensión general de la solución final. Entonces ... ¡manténlo simple! :)

Answer 2

Me gustaría echar un vistazo a EventAggregator en el Composite Application Library. La respuesta en la publicación this tiene una buena descripción de la misma. Jeremy Miller's post entra un poco más de detalle.