¿Dudas en el patrón MVVM?

Question

Estoy creando una aplicación WPF y siguiendo el patrón MVVM. Pero mientras hago las cosas, me preocupo por eso, ¿está de acuerdo con MVVM o no? Por favor guía con estas dudas.

1. ¿Es necesario tener un nuevo ViewModel para cada Vista? De lo contrario, ¿puede crear un solo MasterViewModel una violación de MVVM?

2. ¿Cómo se comunicarán ViewModels?

3. MainWindow.xaml.cs donde estoy integrando todas las Vistas, solo debería tener la inicialización del modelo de vista y asignar el DataContext allí o también puedo poner otros códigos?

4. Estoy teniendo mis EventHandlers definidos. ¿Debo usarlos en ViewModel o fuera de model-view-viewmodel?

Answer 1

Necesita leer algo para hacer en MVVM. Ver las siguientes preguntas:

Good examples of MVVM Template
Good Silverlight-MVVM Practice Example
MVVM Light Toolkit samples

Para sus preguntas:

1. Algunas personas siguen esta regla. : One-ViewModel-Per-View Consulte Rule #2 on this article.

   No es absolutamente necesario seguir esto, pero crear un MasterViewModel como usarlo en todas partes significa que aún no ha entendido MVVM.

   Si se refiere a encapsular bits comunes, sin embargo, tal vez, el MVVM Light Toolkit tiene una clase ViewModelBase para encapsular algunas cosas allí.

2. ViewModels no se comunican entre sí, ViewModels se comunicarán con Vistas, Vistas y se comunicarán con otras vistas (y, posiblemente, una instancia ViewModels para ellos), incluso algunos marcos tienen una forma imprecisa de hacer esto (viene a ReactiveUI mind)

3. Cuando se invoca una vista, puede crear una instancia de su ViewModel correspondiente y luego establecerlo en DataContext. Pero hay muchos patrones diferentes para hacer esto. @Euphporic menciona en los comentarios ViewModel-first donde ViewModels crea Views a través de Ioc. Ver Which came first- The View or ViewModel.

   MVVM Light tiene un localizador de ViewModel que le permite definir un View View Model de forma estática dentro de XAML. Se establecerá automáticamente cuando crees tu vista.

4. No está completamente claro aquí, (a) Si tiene eventos de Botones, Menú, (cualquier cosa que provenga de ButtonBase) debe implementarlos usando el Patrón de Comando. MVVM Light tiene un bonito RelayCommand<T> que te ayudará aquí.

   (b) Otros eventos, MVVM Light tiene el comportamiento de EventToCommand pero Laurent (el autor) advierte sobre esto convirtiéndose en un Patrón Anti.Creo que a veces sólo se podía utilizar eventos de civil en su código detrás y luego llamar a sus ViewModels desde allí (Pero bueno yo no soy un experto aquí)

---

lo solicitado un par de preguntas de todo sobre el lugar. El problema quizás no comprenda el POR QUÉ sobre MVVM.

En términos simples, MVVM le permite mantener lo correcto en el lugar correcto, la lógica/control de la aplicación en ViewModels, y luego con la potencia del enlace de datos Silverlight/WPF conecta sus ViewModels a sus vistas. Como se explica en Laurent, a veces no tiene que ser tan complicado Ni siquiera necesitas un marco todo el tiempo.

Recomiendo ver su video MIX titula - "Comprender el patrón Model-View-ViewModel" desde aquí:
http://live.visitmix.com/Archive#VideoList

Answer 2

IS es necesario contar con un nuevo modelo de vista para todos y cada Vista ? De lo contrario, ¿puede crear un solo MasterViewModel una violación de MVVM?

No, puede tener varias vistas en un modelo de vista única, aunque es típico tener una relación de una vista con un modelo de vista única. Si está pensando en un modelo de vista maestra para todas las vistas, entonces podría volverse inmanejable rápidamente.

¿Cómo se comunicará el ViewModel entre todos?

Existen varias formas, incluidas las referencias directas entre modelos de vista, eventos .NET estándar o un patrón de agregador de eventos.

MainWindow.xaml.cs, donde m integrando todas las vistas, deben tener solamente la inicialización del modelo de vista y asignando el DataContext se allí o que pueden poner otros códigos también?

Típicamente en MVVM, que no tendría ningún (o muy poco) código detrás y utilizar el motor de enlace XAML en una aplicación WPF en lugar de viewmodel/vista de la comunicación.

Estoy teniendo mis EventHandlers definidos. ¿Debo usarlos en ViewModel o fuera de model-view-viewmodel?

No estoy seguro de qué quiere decir con esto, pero puede usar eventos estándar para ver la comunicación del modelo si es necesario.

Consideraría seriamente el uso de un marco de MVVM para su aplicación, siendo mis preferencias personales Caliburn.Micro.

Answer 3

[1] ¿Es necesario tener un nuevo ViewModel para cada Vista? Si no, ¿entonces puede crear un único MasterViewModel es una violación de MVVM?

Por lo general, necesita una nueva instancia de ViewModel para cada instancia de View y una clase de ViewModel diferente para cada clase de View. A veces quieres múltiples Vistas para el mismo Modelo de Vista, lo cual está bien. Si va con el enfoque de ViewModel-first, entonces no siempre necesitará una clase View para cada clase de ViewModel, pero tampoco estaría de más tener una.

[2] ¿Cómo se comunicarán ViewModels?

Si los Modelos de Vista están directamente relacionados (por ejemplo, una relación padre/hijo), una posibilidad es que uno tenga una referencia directa al otro o que uno se suscriba a eventos del otro.

Si los ViewModels son lógicamente independientes, entonces debe usar algún otro mecanismo como Event Aggregator (en Prism) o Messenger (MVVM Light) o equivalente.

[3] MainWindow.xaml.cs donde estoy integrando todas las vistas, deben tener solamente la inicialización del modelo de vista y asignando el DataContext a allí o puedo poner otros códigos también?

No debe inicializar ViewModels en su View code-behind. Los modelos deben ser inyectados en las Vistas por un contenedor de inyección de dependencia (DI).

[4] Estoy teniendo mis EventHandlers definidos. ¿Debo usarlos en ViewModel o fuera de model-view-viewmodel?

No pude entender lo que está preguntando aquí.

Answer 4

1. ¿Es necesario tener un nuevo ViewModel para cada Vista? De lo contrario, ¿puede crear un solo MasterViewModel una violación de MVVM?

No realmente. Puede tener ciertos ViewModels que corresponden a una gran cantidad de vistas, cada una de las cuales muestra los mismos datos en un formato diferente. De hecho, esta es toda la razón de ser de MVVM en primer lugar: segregación de las reglas de visualización y comerciales para que el formato de visualización se pueda cambiar cargando diferentes vistas.

También puede tener una vista que corresponda a una cantidad de modelos de vista diferentes. Esto es reutilización del código en la interfaz de usuario de la pantalla.

2. ¿Cómo se comunicarán ViewModels entre ellos?

Normalmente los modelos de vista se comunican con las vistas a través de la vinculación WPF. Es por eso que se llama MVVM y no MVC.

ViewModels se pueden comunicar entre sí a través de una serie de medios .NET estándar.

3. MainWindow.xaml.cs donde estoy integrando todas las Vistas, solo debería tener la inicialización del modelo de vista y asignar el DataContext ¿o puedo poner otros códigos también?

Normalmente separa cada vista en un archivo XAML diferente.Eso hace que sea fácil sustituir otra vista por un formato diferente de la misma información.

Por lo general, la recomendación es separar el código en módulos autónomos; es decir, un archivo de vista uno, un archivo de modelo de vista uno.

4. Estoy teniendo mis EventHandlers definidos. ¿Debo usarlos en ViewModel o fuera de model-view-viewmodel?

Los eventos deben manejarse en vistas si son puramente impulsados ​​por la interfaz de usuario (es decir, no tiene nada que ver con los datos).

Si un evento debe afectar algún cambio en los datos subyacentes (o realizar alguna acción en las reglas comerciales), a su vez puede generar un evento en el modelo de vista. Tenga en cuenta que este evento en ViewModel puede ser diferente del evento en la Vista/IU.