c# - ¿Dudas en el patrón de MVVM?

wpf c#-4.0

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 entre ellos?

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

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

Answer 1

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

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

¿Cómo todos los ViewModel se comunicarán entre ellos?

Hay 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 estoy integrando todas las Vistas, debería tener solo la inicialización del modelo de vista y asignar el DataContext allí o ¿puedo poner otros códigos también?

Por lo general, en MVVM, no tendrías (o muy poco) código atrás y usarás el motor de enlace XAML en una aplicación WPF para ver la comunicación viewmodel / view.

Tengo 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 MVVM para su aplicación, siendo mi preferencia personal Caliburn.Micro .

Answer 2

[1] ¿Es necesario tener un nuevo ViewModel para cada Vista? De lo contrario, ¿puede crear un solo MasterViewModel 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 verán los ViewModels?

Si los Modelos de Vista están directamente relacionados (por ejemplo, una relación padre / hijo), entonces una posibilidad es que uno tenga una referencia directa al otro o que uno se suscriba a los 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, solo debería tener la inicialización de viewmodel y asignar el DataContext allí o también puedo poner otros códigos?

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] Tengo mis EventHandlers definidos. ¿Debo usarlos en ViewModel o fuera de model-view-viewmodel?

No pude entender lo que estás preguntando aquí.

Answer 3

Necesitas algo de lectura para hacer en MVVM. Vea las siguientes preguntas:

Buenos ejemplos de plantilla MVVM
Buen ejemplo de práctica de Silverlight-MVVM
Ejemplos de MVVM Light Toolkit

Para sus preguntas:

1. Algunas personas siguen esta regla. : One-ViewModel-Per-View Vea la Regla # 2 en este artículo .

   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, quizás el MVVM Light Toolkit tenga una clase ViewModelBase para encapsular algunas cosas allí.

2. ViewModels no se comunicará entre sí, ViewModels se comunicará con Views, y Views se comunicará con otras Views (y posiblemente instanciará ViewModels para ellas) algunos frameworks incluso tienen una forma ligeramente acoplada de hacer esto ( ReactiveUI viene a la mente)

3. Cuando se llama a 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 lo que vino primero- The View o ViewModel .

   MVVM Light tiene un localizador 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 se derive de ButtonBase) debe implementarlos usando el Patrón de Comando. MVVM Light tiene un agradable RelayCommand<T> que te ayudará aquí.

   (b) Otros eventos, MVVM Light tiene comportamiento de EventToCommand, pero Laurent (el autor) advierte que esto se convertirá en un Patrón Anti. Creo que a veces puedes simplemente usar eventos simples en tu código y luego llamar a tus ViewModels desde allí (Pero oye, no soy un experto aquí)

Has hecho un par de preguntas por todos lados. El problema tal vez no entiendes el POR QUÉ sobre MVVM.

En términos simples, MVVM le permite mantener lo correcto en el lugar correcto, la lógica / control de su aplicación en ViewModels y luego, con la potencia del enlace de datos de Silverlight / WPF, puede conectar sus ViewModels a sus vistas.

Como explica Laurent , a veces no tiene por qué ser tan complicado. Ni siquiera necesitas un marco todo el tiempo.

Recomiendo ver su video MIX titulado - "Entender el Modelo-Vista-Patrón de modelo de vista" desde aquí:
http://live.visitmix.com/Archive#VideoList

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?

Realmente no. 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?

Por lo general, ViewModels se comunica con Views mediante WPF Binding. Es por eso que se llama MVVM y no MVC.

ViewModels puede comunicarse 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 de viewmodel y asignar el DataContext allí o también puedo poner otros códigos.

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

Generalmente, la recomendación es separar su código en módulos autónomos; es decir, un archivo de vista uno, un modelo de vista un archivo.

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

Los eventos deberían ser manejados en vistas si son puramente impulsados ​​por UI (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 sobre las reglas comerciales), puede, a su vez, generar un evento en ViewModel. Tenga en cuenta que este evento en ViewModel puede ser diferente del evento en la Vista / IU.