Шаблон MVVM: Обновления ViewModel после обхода сервера модели

Question

У меня есть службы без сохранения состояния и объекты анемичного домена на стороне сервера. Модель между сервером и клиентом - POCO DTO. Клиент должен стать MVVM. Модель может быть графом около 100 экземпляров 20 различных классов. Редактор клиента содержит различные вкладки, все они в реальном времени связаны с моделью / моделью представления.

Моя проблема в том, как распространять изменения после обхода сервера хорошим способом. Очень легко распространять изменения из ViewModel в DTO. Для обратного пути можно было бы выбросить старый DTO и заменить его полностью новым, но это вызовет много перерисовок для списков / DataTemplates.

Я мог бы собрать изменения на стороне сервера и передать их на сторону клиента. Но имена измененных полей будут зависеть от домена / DTO, а не от ViewModel. И отображение мне кажется нетривиальным. Если бы я сделал это обязательным образом после кругового обхода, это нарушило бы SOC / модульность viewModels.

Я имею в виду какой-то механизм правил отображения, что-то вроде automappper или emit mapper. Но это решает только очень простые варианты использования. Я не вижу, как это будет отображать / распространять / преобразовывать добавление элементов в список или удаление. Как идентифицировать экземпляры в коллекциях, чтобы они могли объединять значения с существующими экземплярами. Кроме того, он должен распространять информацию о проверке / ошибке.

Может быть, я должен реализовать INotifyPropertyChanged на DTO и попытаться воспроизвести на нем события на стороне сервера? А потом привязать ViewModel к нему? Решит ли связывание проблемы с слиянием коллекций хорошим способом? Является ли EventAgregator из PRISM полезным для этого? Есть ли какой-либо компонент воспроизведения записи события?

Есть ли лучший клиентский шаблон для архитектуры с серверной логикой?

Answer 1

Как правило, я держал ссылку на DTO в моих классах модели. Для нескольких моделей я гарантирую, что каждая модель знает, как создать себя из DTO, а также как сохранить себя, используя необратимый «хранитель» или другой объект поставщика услуг. Перенос ссылки на DTO упрощает, когда вы вызываете Save () для модели, чтобы изменить старый DTO в соответствии с моделью, прежде чем передать его обратно в сервис.

Надеемся, что любые "обновления" других объектов после операции Save () могут быть переданы в другие DTO, которые затем должны быть загружены в соответствующие классы Model, используемые вашей ViewModel.

Недостатком является то, что вам действительно нужно написать код отображения, но обычно это самая простая часть. Я не уверен, что это лучший способ сделать что-то, и я был бы признателен за чтение ответов других.

Answer 2

Я использовал другой вариант с большим успехом. У нас был графический интерфейс в реальном времени, поэтому повторные перерисовки на клиенте были неприемлемы.

Мы сообщили нашим DTO об изменениях их свойств и отправили PropertyChanged события в ViewModel, таким образом воспроизводя события на стороне сервера.

Код прост для написания, модульного тестирования и т. Д. Его становится легко просматривать, когда набирается PropertyChangeListeners (интерфейсы, реализованные ViewModels).

Эту границу также можно использовать для переключения потоков в рабочий поток графического интерфейса.