Przesyłanie wartości i komunikacja między ViewModel'ami

Witam,

Chciałem zapytać, w jaki sposób mogę przesłać dane z jednego ViewModel do innego?

Na przykład, mam LoginViewModel, który jest odpowiedzialny za sprawdzenie w bazie czy użytkownik istnieje a następnie z tabeli pobiera dane które wyświetlane są na jednym z UserControl. Chciałbym te ściągnięte dane wysłać do Property na innym ViewModel, aby ten mógł również wykonać operację wykorzystując te wartości. (Account, Team, Tower, Process - tego typu dane - Stringi). Chciałem wykorzystać do tego Messenger z MVVM Light oraz klasę Tuple, jednak na tym ViewModel który ma rejestrować wiadomośc w konstruktorze mam inny Messenger (tutaj jest dla pojedynczego Stringa, a ten musiałby być dla Tuple)

Więc pytanie, czy można umieści dwa Messengery w konstruktorze jednego ViewModelu? Albo czy jest jakieś inne rozwiązanie na komunikację pomiędzy ViewModelami?

Możesz sobie zrobić jakąś jedną klasę statyczną np UserConfig, która będzie dla całej aplikacji i w niej będziesz przechowywać sobie informacje które są podstawowymi danymi dla działania aplikacji. Możesz również zrobić sobie Event i się pod niego podpiąć, a następnie z niego skorzystać.

W swoich projektach tworzę sobie do tego Singletony. Mam sobie klasę z polami, które mi są potrzebne i przekazuję sobie jej instancję między ViewModelami. Klasa statyczna też jest dobrym pomysłem i działa w praktyce prawie tak samo jak Singleton.

Z drugiej strony staram się jednak unikać takich klas przekaźnikowych i używam ich tylko wtedy kiedy już nie mam innego wyjścia. W WPF jeżeli chce przekazać dane z jednego VM do drugiego VM robię to zwyczajnie przez konstruktor okna i w codebehind binduję sobie datacontext do ViewModelu. Eliminuje to ciągłe wykorzystanie VM z konstruktorem bezparametrowym w przypadku bindowania VM przez XAML. :)

No chyba, że dużo jest tych obiektów to tworzę sobie klasę pomocniczą.

Static to będzie chyba najlepsze rozwiązanie. Jeszcze może spróbuję z Delegates...

Byłem przekonany ze Messenger będzie dobrym rozwiązaniem, ale też trzeba to czasami przekombinować.

Singletonów się boje :D

Singletony i statiki są dobre np do zarządzania przekazywaniem danych (obsługa jakiegoś SQL'a, obsługa operacji na plikach itp.), gdzie potrzebujesz jedną instancję w całym projekcie. Do trzymania konfiguracji etc. Do samego przekazania danych można użyć zwykłego konstruktora klasy docelowej chyba, że jest tak jak napisał @Unlimited. Dlaczego? Ponieważ może się później okazać, że naprodukujesz statików czy Singletonów tam gdzie zwyczajnie możesz przekazać dane przez konstruktor.

Zamiast statycznych klas proponował bym użycie kontenera i zarejestrować tam klasę USER jako singleton. Następnie za pomocą DI odwoływać się do tego zasoby w poszczególnych zasobach. Dodatkowo taką klasę USER możesz obrać w Observable i zapisywać się na zmianę stanu.

RiderOfTheli napisał(a):

Na przykład, mam LoginViewModel, który jest odpowiedzialny za sprawdzenie w bazie czy użytkownik istnieje a następnie z tabeli pobiera dane które wyświetlane są na jednym z UserControl.

Czemu ViewModel pobiera coś z tabeli?

Chciałbym te ściągnięte dane wysłać do Property na innym ViewModel, aby ten mógł również wykonać operację wykorzystując te wartości. (Account, Team, Tower, Process - tego typu dane - Stringi).

Nie przesyłaj danych między ViewModelami, tylko uzupełniaj oba ViewModele danymi z jednego źródła.

Ogólnie Twój problem wynika z braku podziału aplikacji na warstwy logiczne i próby robienia wszystkiego w logice GUI.

grzesiek51114 napisał(a):

Klasa statyczna też jest dobrym pomysłem i działa w praktyce prawie tak samo jak Singleton.

Klasa statyczna nigdy nie jest dobrym pomysłem. Nie da się jej zrobić immutable, nie da się dziedziczyć nie da się zapanować nad tym, co kiedy jest zmieniane.

Prawidłowym rozwiązaniem jest zwykła klasa z danymi ustawianymi w konstruktorze, dostępnymi publicznie tylko do odczytu, i zarejestrowana jako singleton w kontenerze IoC.