Wzór MVVM: Aktualizacje programu ViewModel po obiedzie modelu modelu

Question

Mam usługi bezpaństwowe i obiekty domeny anemicznej po stronie serwera. Model pomiędzy serwerem a klientem to POCO DTO. Klient powinien stać się MVVM. Model może być wykresem około 100 przykładów 20 różnych klas. Edytor klienta zawiera różne strony z zakładkami, wszystkie z podłączonymi na żywo do modelu/viewmodel.

Mój problem polega na tym, jak propagować zmiany po ładowaniu w obie strony. Bardzo łatwo jest przenosić zmiany z ViewModel na DTO. W drodze powrotnej można wyrzucić starego DTO i zastąpić go nowym, ale spowoduje to wiele przerysowań dla list/DataTemplates.

Mogłem zebrać zmiany po stronie serwera i przesłać je do strony klienta. Ale zmienione nazwy pól będą dotyczyły konkretnej domeny/DTO, a nie specyficznych dla ViewModel. Mapowanie wydaje mi się nietrywialne. Gdybym zrobił to w sposób imperatywny po podróży w obie strony, złamałoby to SOC/modularność viewModels.

Zastanawiam się nad jakimś silnikiem reguł mapowania, czymś w rodzaju automapppera lub emulatora. Ale rozwiązuje tylko bardzo proste przypadki użycia. Nie widzę sposobu, w jaki mapował/propagował/konwertował dodawanie elementów do listy lub usuwania. Jak zidentyfikować instancje w kolekcjach, aby scalić wartości z istniejącymi instancjami. Jak również powinien propagować informacje o walidacji/błędzie.

Może powinienem wdrożyć INotifyPropertyChanged na DTO i spróbować powtórzyć zdarzenia po stronie serwera? A następnie związać do niego ViewModel? Czy wiązanie rozwiązać problemy z kolekcją łączy się w miły sposób? Czy EventAgregator z PRISM jest do tego przydatny? Czy jest jakiś komponent zapisu nagrań zdarzenia?

Czy istnieje lepszy wzór po stronie klienta dla architektury z logiką po stronie serwera?

Answer 1

Zazwyczaj zachowuję odniesienie do DTO w moich klasach modeli. W przypadku wielu modeli zapewniam, że każdy model wie, jak zbudować się z DTO, a także jak zapisać się za pomocą "wygaszacza" do wstrzykiwania lub innego obiektu dostawcy usług. Przeniesienie odniesienia do DTO sprawia, że ​​łatwo jest, gdy wywołasz Save() na modelu, aby zmodyfikować stary DTO zgodnie z Modelem przed przekazaniem go z powrotem do usługi.

Mam nadzieję, że wszelkie "aktualizacje" innych obiektów po operacji Save() mogą być przesyłane w innych DTO, które następnie powinny zostać załadowane do odpowiednich klas modeli używanych przez twój ViewModel.

Wadą tego jest to, że rzeczywiście trzeba napisać kod mapowania, ale zazwyczaj jest to najłatwiejsza część. Nie jestem przekonany, że to najlepszy sposób robienia rzeczy i byłbym wdzięczny za przeczytanie odpowiedzi innych.

Answer 2

Użyłem innej odmiany z dużym sukcesem. Mieliśmy GUI w czasie rzeczywistym, więc powtarzalne przerysowania na kliencie były nie do przyjęcia.

Uczyliśmy naszych DOT o zmianach w ich własnościach i emitujemy zdarzenia PropertyChanged do ViewModel, co pozwala odtworzyć zdarzenia po stronie serwera.

Kod jest prosty do napisania, testu jednostkowego itp. Łatwo jest przeglądać po wpisaniu PropertyChangeListeners (interfejsów zaimplementowanych przez ViewModels).

Ta granica może być również używana do przełączania wątków do wątku roboczego GUI.