Patrón de MVVM: actualizaciones de ViewModel después de ida y vuelta del servidor modelo

Question

Tengo servicios sin estado y objetos de dominio anémicos en el lado del servidor. El modelo entre el servidor y el cliente es POCO DTO. El cliente debe convertirse en MVVM. El modelo podría ser un gráfico de aproximadamente 100 instancias de 20 clases diferentes. El editor del cliente contiene diversas páginas con pestañas, todas ellas conectadas en vivo al modelo/viewmodel.

Mi problema es cómo propagar los cambios después del servidor de ida y vuelta buena manera. Es bastante fácil propagar los cambios de ViewModel a DTO. De regreso, sería posible descartar el viejo DTO y reemplazarlo por uno nuevo, pero causará un gran rediseño para las listas/DataTemplates.

Pude recoger los cambios del lado del servidor y transmitirlos al lado del cliente. Pero los nombres de los campos modificados serían específicos del dominio/DTO, no específicos de ViewModel. Y el mapeo no me parece trivial. Si lo hiciera de manera imperativa después del viaje de ida y vuelta, rompería SOC/modularidad de viewModels.

estoy pensando en algún tipo de motor de reglas de asignación, algo así como automappper o emitir asignador. Pero resuelve casos de uso muy simples. No veo cómo mapear/propagar/convertir agregar elementos a la lista o eliminación. Cómo identificar instancias en colecciones para que pueda fusionar valores a instancias existentes. Además, debería propagar la información de validación/error.

Tal vez debería aplicar INotifyPropertyChanged en DTO y tratar de reproducir eventos del lado del servidor en él? ¿Y luego vincular ViewModel a ella? ¿Sería vinculante solucionar los problemas con la colección se fusiona de manera agradable? ¿EventAgregator de PRISM es útil para eso? ¿Hay algún componente de grabación de eventos?

¿Hay un mejor patrón del lado del cliente para la arquitectura con la lógica del lado del servidor?

Answer 1

Por lo general, me he mantenido una referencia a la DTO en mis clases de modelos. Para múltiples modelos, me aseguro de que cada modelo sepa cómo construirse a partir de un DTO, así como cómo guardarse usando un "protector" no inyectable u otro objeto de proveedor de servicios. Llevar una referencia al DTO lo hace bastante fácil, cuando llama a Save() en el modelo, para modificar el viejo DTO de acuerdo con el Modelo antes de devolverlo al servicio.

Afortunadamente, cualquier "actualización" de otros objetos después de una operación Guardar() podría comunicarse en otros DTO, que luego deberían cargarse en las clases de modelo apropiadas utilizadas por su ViewModel.

La desventaja de esto es que en efecto tiene que escribir el código de asignación, pero esto suele ser la parte más fácil. No estoy seguro de que esta sea la mejor manera de hacer las cosas y agradecería leer las respuestas de los demás.

Answer 2

He usado otra variación con mucho éxito. Teníamos una GUI en tiempo real, por lo que los redibujados repetitivos en el cliente no eran aceptables.

Hemos hecho que nuestros DTO estén al tanto de los cambios en sus propiedades y emitan los eventos PropertyChanged al ViewModel, reproduciendo así los eventos del lado del servidor.

El código es sencillo de escribir, prueba de unidad, etc. Se vuelve fácil de navegar cuando se tipean PropertyChangeListeners (interfaces implementadas por ViewModels).

Este límite también se puede utilizar para cambiar hilos para el subproceso de trabajo GUI.