UI представление объекта сервера

Question

У меня есть приложение, в котором создается много объектов и чьи свойства часто меняются пользователем.На сервере имеются различные модули, и для каждого модуля создается один сеанс.Каждый сеанс состоит из одного клиента и одного пользователя, работающего с основным приложением.Пользователь просто вмешивается в объекты и изменяет его свойство, в настоящее время я использую сетку свойств в форме окна, чтобы сделать это.Как клиент будет подключен к основному приложению, еще предстоит решить.Я думаю о дуплексном сервисе WCF.Мне нужно два предложения:

1. Как представить удаленные объекты на клиентском интерфейсе?Я думал о создании элементов пользовательского интерфейса вручную в конструкторе форм VS и размещении XML-файла сопоставления, который при инициализации пользовательского интерфейса использует таблицу сопоставления для получения сведений о свойствах каждого элемента пользовательского интерфейса и соответствующего изменения.Подобно тому, как панель в пользовательском интерфейсе будет заполнена каким-то цветом, когда ошибочное состояние сопоставленного объекта будет истинным.

2. Поскольку объекты на сервере часто меняются, лучше всего сказать клиенту:обновить пользовательский интерфейс.Я думал о дуплексном WCF, где, если клиент зарегистрирован для определенного объекта, он будет уведомлен об изменении объекта.Мой вопрос заключается в том, должны ли мы передавать весь объект клиенту или только обновленное свойство вместе с идентификатором объекта (в новом типе)

   interface IChange
   {
       string ObjectName { get; set; }
       string PropertyName { get; set; }
       object NewValue { get; set; }
       object OldValue { get; set; }
   }
   

Предложить мне альтернативный или лучший способ достижения моей цели

РЕДАКТИРОВАТЬ

На данный момент ни один из объектов не так много, но он может резко возрасти.Это приложение на основе плагинов, и разработчик может добавить тысячи объектов + может быть несколько плагинов.Размер объекта я не ожидаю, чтобы быть выше, чем 10-20kB, но это не определено.Дело в том, что если я отправляю весь объект клиенту (90% объекта бесполезен, клиенту обновляется только обновленное свойство), клиент должен просмотреть все свойства и обновить пользовательский интерфейс.Но если я отправляю только изменения клиенту, тогда клиент знает, что изменить.Обновления объектов могут быть очень частыми, так как любое изменение в одном свойстве объекта вызывает несколько изменений в других объектах (вид цепной реакции), и обо всех изменениях следует уведомлять.Например, если я изменю свойство IsOn главного выключателя в моем доме, все приборы будут отключены.И обо всех таких изменениях объекта необходимо сообщать клиенту.Как только клиент получит уведомление о закрытии каждого объекта, он отобразит все устройства в пользовательском интерфейсе как неработающие.

Answer 1

Мой вопрос заключается в том, должны ли мы передавать весь объект клиенту или только обновленное свойство вместе с идентификатором объекта (в новом типе)?

Производительность : зависит от размера объектов данных и их количества в любое время. Например, если у вас есть 1000 объектов, каждый из которых имеет размер 1 МБ, с 1000 различными свойствами и в среднем выполняется только 1 или 2 незначительных изменения, то имеет смысл отправлять только изменения.

• Меньшая нагрузка на сеть
• Меньше памяти / интенсивность обработки
• Особенно верно, если вам нужно десериализовать много XML.

Сложность : Иногда легче просто сдуть все, что изменилось, и начать с нуля; вам не нужно сильно беспокоиться о поддержании состояния объекта, обработке нескольких изменений в одном и том же объекте и т. д.

Поскольку объекты на сервере часто меняются, что является лучшим способ сказать клиенту обновить пользовательский интерфейс?

Возвращается к числу вероятных объектов, как часто они меняются и откуда они берутся (« Как клиент будет подключен к основному приложению, еще предстоит решить »). Также зависит от того, насколько современным должен быть пользовательский интерфейс. Если объект изменяется на сервере, и у вас есть 100 клиентов, которые необходимо обновить - как скоро они должны быть обновлены?

Имейте в виду, что чем чаще и быстрее происходят изменения, тем более «болтливым» будет ваше приложение, которое начнет снижать производительность, чем больше границ вы будете пересекать (домен, процесс, сервер, сеть ...).

Редактировать

Похоже, что единица работы шаблон может помочь:

• Пусть все вступающие в силу изменения вступают в силу при поступлении запроса на изменение.
• Затем отправьте все изменения (дельты, а не целые объекты) как один «пакет» / набор обратно вызывающей стороне.
• Возможно, используйте какой-то кэш, если у вас много клиентов, которым нужны новые данные.