wpf - ventajas - patrones mvc mvvm

Silverlight: comunica entre 2 modelos de vista en MVVM usando comandos

Question

Estoy trabajando en MVVM y usando comandos en Silverlight (DelegateEvent e ICommand)

Quiero algo así, (decir) tengo 2 controles de usuario, padre e hijo.

Los padres son anfitriones del niño, ambos tienen sus propios modelos de vista.

En Parent tengo un botón y ejecuta un comando simple, al ejecutar ese comando quiero actualizar el texto en el cuadro de texto del control secundario. también deberíamos poder cambiar algo en el niño que pueda propagarse al padre.

Los eventos son la mejor respuesta para esto o puedo tener comandos para actualizar el elemento secundario / notificar a los padres de alguna manera.

Answer 1

Esto parece una situación ideal para usar un EventAggregator como el que se encuentra en la Guía de Aplicación Compuesta / Prisma.

En este modelo, puede configurar un MessageBus en la raíz de la aplicación (u otra área común).

// en App.xaml.cs

public static IEventAggregator MessageBus = new EventAggregator ();

Luego configure una biblioteca común de Mensajes

// in Messages.cs
public class SimpleCommand: CompositePresentationEvent<SimpleObject> { }

Donde SimpleObject es una clase o variable que contiene toda la información necesaria para procesar este evento.

// in control with button
App.MessageBus.GetEvent<Messages.SimpleCommand>().Publish(SimpleObject);
// anywhere in your app that you "care" about this
App.MessageBus.GetEvent<Messages.SimpleCommand>().Subscribe(ProcessingMethod);

Donde ProcessingMethod es un método que toma un SimpleObject como parámetro.

Luego puede enviar mensajes desde cualquier lugar y procesarlos en cualquier lugar: a través de viewmodels, controles, etc. Incluso puede pasar MessageBuses entre componentes si está cargando partes de la aplicación dinámicamente. Funciona bien.

Answer 2

Hay varias formas de hacerlo.

En primer lugar, es completamente apropiado tener ViewModels que están compuestos de otros ViewModels, siempre y cuando esté bien con ellos acoplados de esa manera. Cuando haces eso, pueden hablar entre ellos usando llamadas a métodos regulares.

Luego, puedes desacoplar un poco y usar eventos. Nada de malo con eso. Todavía hay un Observer -> acoplamiento observable, pero son menos dependientes el uno del otro.

A continuación, puede desacoplar por completo y utilizar algo como un EventAggregator (Prism tiene uno bueno que puede usar). Dispara a Publicar un mensaje. El otro se suscribe. No se conocen el uno del otro en absoluto.

También he usado comandos para esto ... pero para la comunicación de ViewModel a ViewModel, encuentro que esto es un poco incómodo.

Answer 3

Probablemente debería comenzar con la implementación más obvia, donde el modelo de vista padre simplemente contiene una referencia a un modelo de vista hijo, y el modelo de vista hijo contiene una referencia a un modelo de vista padre. Luego, cuando se ejecuta un comando en el modelo de vista padre, simplemente establece un valor en un modelo de vista hijo al que está vinculado el cuadro de texto.

Agregar una capa de abstracción entre padres e hijos (por ejemplo, eventos) agrega un nivel de complejidad y, como resultado, debe estar justificado. Si el valor que proporciona esta indirección es mayor que el costo de una mayor complejidad del código (p. Ej. Ahora está menos claro qué sucede cuando se ejecuta el comando en un padre, tendrás que resolver un problema de cómo el niño se suscribe al evento principal sin obtener el la referencia real al mismo y viceversa, agregar dependencias adicionales entre el padre y el hijo requerirá agregar eventos adicionales, que contaminan la lógica real con todas las tuberías, etc.) entonces ciertamente los eventos (o algo así como PropertyObserver ) podrían ser un próximo paso lógico .