Forma correcta de usar MVVM Light Messenger

Question

¿Cuál es la forma correcta de usar la clase Messenger? Sé que se puede usar para comunicaciones ViewModels/Views, pero ¿es una buena forma de utilizarlo para una capa de servicio técnico/comercial?

Por ejemplo, un servicio de registro/navegación registra algunos mensajes en los constructores y sabe cuándo se producen estos mensajes en la aplicación. El remitente (ViewModel ou Service) no hace referencia a la interfaz de servicio, sino solo a Messenger para enviar mensajes. Este es un servicio de muestra:

using System; 
using System.Windows; 
using System.Windows.Navigation; 
using Microsoft.Phone.Controls; 
using App.Service.Interfaces; 
using GalaSoft.MvvmLight.Messaging; 

namespace App.Service 
{ 
    public class NavigationService : INavigationService 
    { 
     private PhoneApplicationFrame _mainFrame; 

     public event NavigatingCancelEventHandler Navigating; 

     public NavigationService() 
     { 
      Messenger.Default.Register<NotificationMessage<Uri>>(this, m => { this.NavigateTo(m.Content); }); 
     } 

     public void NavigateTo(Uri pageUri) 
     { 
      if (EnsureMainFrame()) 
      { 
       _mainFrame.Navigate(pageUri); 
      } 
     } 

     public void GoBack() 
     { 
      if (EnsureMainFrame() 
       && _mainFrame.CanGoBack) 
      { 
       _mainFrame.GoBack(); 
      } 
     } 

     private bool EnsureMainFrame() 
     { 
      if (_mainFrame != null) 
      { 
       return true; 
      } 

      _mainFrame = Application.Current.RootVisual as PhoneApplicationFrame; 

      if (_mainFrame != null) 
      { 
       // Could be null if the app runs inside a design tool 
       _mainFrame.Navigating += (s, e) => 
       { 
        if (Navigating != null) 
        { 
         Navigating(s, e); 
        } 
       }; 

       return true; 
      } 

      return false; 
     } 
    } 
} 

Answer 1

Para mí, el principal uso de un mensajero es debido a que permite la comunicación entre ViewModels. Supongamos que tiene un modelo de vista que se utiliza para proporcionar lógica de negocios a una función de búsqueda y 3 modelos de vista en su página/ventana que desean procesar la búsqueda para mostrar el resultado, el mensajero sería la forma ideal de hacerlo de forma flexible. camino.

El modelo de vista que obtiene los datos de búsqueda simplemente enviaría un mensaje de "búsqueda" que sería consumido por cualquier cosa que estuviera actualmente registrada para consumir el mensaje.

Los beneficios aquí son:

1. fácil comunicación entre el uno sin el modelo de vista ViewModels tener que saber el uno del otro
2. puedo intercambiar el productor sin afectar a un consumidor.
3. Puedo agregar más consumidores de mensajes con poco esfuerzo.
4. mantiene a los ViewModels simples

Editar: Así que, ¿qué pasa con los servicios?

ViewModels se trata de cómo presentar datos en la interfaz de usuario. Toman sus datos y los forman en algo que se puede presentar a su Vista. ViewModels obtiene sus datos de los servicios.

Un servicio proporciona la lógica de datos y/o negocio al ViewModel. El trabajo de servicios consiste en atender solicitudes de modelos comerciales. Si un servicio necesita comunicarse/usar otros servicios para hacer su trabajo, estos deben ser inyectados en el servicio usando la inyección de dependencia. Los servicios normalmente no se comunican entre ellos usando un messenger. El messenger se trata mucho de comunicación horizontal en el nivel de viewmodel.

Una cosa que he visto hacer es usar un messenger como mediator, donde en vez de inyectar el servicio directamente en un modelo de vista, el messenger se inyecta en el modelo de vista. El modelo de vista se suscribe a un evento y recibe eventos que contienen modelos del evento. Esto es excelente si recibe un flujo constante de actualizaciones o si recibe actualizaciones de múltiples servicios que desea fusionar en una sola transmisión.

Usar un messenger en lugar de inyectar un servicio cuando está haciendo solicitudes de solicitud/respuesta no tiene ningún sentido, ya que tendrá que escribir más código para hacer esto que tendría que escribir simplemente inyectando el servicio directamente y hace que el código sea difícil de leer.

Mirando su código, arriba. Imagínese si tuviera que escribir un evento para cada método allí (Navegar, CanNavigate, GoBack, GoForward, etc.). Terminarías con muchos mensajes. Tu código también sería más difícil de seguir.