Właściwy sposób korzystania z MVVM Light Messenger

Question

Jaki jest właściwy sposób korzystania z klasy Messenger? Wiem, że może być używany do komunikacji ViewModels/Views, ale czy jest dobrym podejściem do używania go w warstwie technicznej/biznesowej usługi?

Na przykład rejestracja/rejestracja usług rejestruje niektóre wiadomości w konstruktorach i jest świadoma, kiedy te wiadomości występują w aplikacji. Nadawca (usługa ViewModel ou) nie odwołuje się do interfejsu usługi, a jedynie wysyła wiadomości do komunikatora. Oto przykładowy serwis:

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

Dla mnie głównym zastosowaniem jest posłańca, ponieważ pozwala na komunikację pomiędzy ViewModels. Powiedzmy, że masz viewmodel, który jest używany do dostarczenia logiki biznesowej do funkcji wyszukiwania i 3 viewmodels na twojej stronie/oknie, które chcą przetworzyć wyszukiwanie, aby pokazać wyjście, messenger byłby idealnym sposobem na zrobienie tego w luźno związanym droga.

Model poglądowy, który pobiera dane wyszukiwania, po prostu wyśle ​​wiadomość "wyszukiwania", która zostanie zużyta przez wszystko, co zostało zarejestrowane do odebrania wiadomości.

Tutejsze korzyści to:

1. łatwa komunikacja między każdym viewmodel ViewModels bez konieczności wiedzieć o siebie
2. mogę zamienić się producentowi bez wpływu na konsumenta.
3. Mogę dodać więcej użytkowników wiadomości przy niewielkim wysiłku.
4. Utrzymuje ViewModels prostych

Edit: Więc, co o usługach?

ViewModels dotyczą sposobu prezentacji danych w interfejsie użytkownika. Biorą twoje dane i kształtują je w coś, co można zaprezentować Twojemu Widokowi. ViewModels pobiera dane z usług.

Usługa dostarcza dane i/lub logikę biznesową do ViewModel. Zadaniem usługi jest obsługa zgłoszeń dotyczących modeli biznesowych. Jeśli usługa wymaga komunikacji/korzystania z innych usług w celu wykonania swojej pracy, należy ją wprowadzić do usługi za pomocą wstrzyknięcia zależności. Usługi zwykle nie komunikują się ze sobą za pomocą komunikatora. Komunikator w dużym stopniu dotyczy komunikacji poziomej na poziomie widoku.

Jedną z rzeczy, które widziałem, to użycie komunikatora jako mediator, gdzie zamiast wstrzykiwania usługi bezpośrednio do modelu podglądu zamiast tego jest wysyłany komunikator do modelu widoku. Viewmodel subskrybuje wydarzenie i otrzymuje zdarzenia zawierające modele ze zdarzenia. To świetnie, jeśli otrzymujesz stały przepływ aktualizacji lub otrzymujesz aktualizacje z wielu usług, które chcesz scalić w jeden strumień.

Posługiwanie się komunikatorem zamiast wstrzykiwania usługi podczas wykonywania żądań typu żądanie/odpowiedź nie ma sensu, ponieważ będziesz musiał napisać więcej kodu, aby to zrobić, że będziesz musiał napisać po prostu wstrzyknięcie usługa bezpośrednio i sprawia, że ​​kod jest trudny do odczytania.

Patrząc na swój kod, powyżej. Wyobraź sobie, że musisz napisać wydarzenie dla każdej z metod (Navigate, CanNavigate, GoBack, GoForward itp.). W efekcie otrzymasz wiele wiadomości. Twój kod byłby trudniejszy do naśladowania.