Pattern MVVM: aggiornamenti di ViewModel dopo il round trip del modello Model

Question

I servizi stateless e gli oggetti di dominio anemico sul lato server. Il modello tra server e client è POCO DTO. Il client dovrebbe diventare MVVM. Il modello potrebbe essere un grafico di circa 100 istanze di 20 classi diverse. L'editor client contiene diverse pagine di tabulazione tutte collegate in diretta a model/viewmodel.

Il mio problema è come propagare le modifiche dopo il round trip del server. È abbastanza semplice propagare le modifiche da ViewModel a DTO. Per il ritorno sarebbe possibile gettare via il vecchio DTO e rimpiazzarlo con uno nuovo, ma causerà molto ridisegno per liste/DataTemplates.

È possibile raccogliere le modifiche sul lato server e trasmetterle al client. Ma i nomi dei campi modificati sarebbero specifici per dominio/DTO, non per ViewModel specifico. E la mappatura mi sembra non banale. Se dovessi farlo in modo imperativo dopo il round-trip, si romperebbe SOC/modularity of viewModels.

Sto pensando a qualche tipo di motore di regole di mappatura, qualcosa come automappper o emit mapper. Ma risolve solo casi d'uso molto semplici. Non vedo come sarebbe mappare/propagare/convertire aggiungere elementi all'elenco o rimozione. Come identificare le istanze nelle raccolte in modo da poter unire i valori alle istanze esistenti. Inoltre dovrebbe propagare le informazioni di convalida/errore.

Forse dovrei implementare INotifyPropertyChanged su DTO e provare a riprodurre eventi lato server su di esso? E quindi associare ViewModel ad esso? Vincolerebbe risolvere i problemi con la raccolta si fonde in modo carino? È utile EventAgregator di PRISM? Esiste un componente di registrazione di un evento?

Esiste un modello di lato client migliore per l'architettura con logica lato server?

Answer 1

In genere, ho mantenuto un riferimento al DTO nelle mie classi Model. Per i modelli multipli, assicuro che ciascun modello sappia come costruirsi da un DTO, nonché come salvare se stesso utilizzando un "risparmiatore" iniettabile o un altro oggetto fornitore di servizi. Portare un riferimento al DTO rende abbastanza facile, quando si chiama Salva() sul modello, per modificare il vecchio DTO in base al Modello prima di restituirlo al servizio.

Eventualmente ogni "aggiornamento" ad altri oggetti dopo un'operazione di salvataggio() potrebbe essere comunicato in altri DTO, che dovrebbero quindi essere caricati nelle classi modello appropriate utilizzate dal ViewModel.

Lo svantaggio di questo è che devi scrivere il codice di mappatura, ma di solito è la parte più semplice. Non sono convinto che questo sia il modo migliore per fare le cose e mi farebbe piacere leggere le risposte degli altri.

Answer 2

Ho usato un'altra variante con molto successo. Avevamo una GUI in tempo reale, quindi i ripetuti ripetuti ritocchi sul client non erano accettabili.

Abbiamo reso i nostri DTO consapevoli delle loro modifiche alle proprietà ed emettono eventi PropertyChanged su ViewModel, quindi riproduciamo eventi lato server.

Il codice è semplice da scrivere, unit test, ecc. Diventa facile scorrere quando vengono digitati PropertyChangeListeners (interfacce implementate da ViewModels).

Questo limite può anche essere utilizzato per passare i thread al thread di lavoro della GUI.