Синхронизация нескольких представлений, редакторов и фиксация / отмена

Question

Мы думаем об архитектуре, поддерживающей несколько видов и редакторов для одного и того же объекта. Требование - это возможность зафиксировать или отменить изменения, сделанные для всего объекта.

Наши требования - множество объектов, отредактированных одновременно (до 10.000 в режиме множественного выбора) - несколько просмотров и редакторов одновременно - изменения в редакторе объекта должны отражаться только в других представлениях после успешной фиксации. - объекты в редакторе должны быть коммитируемыми / отменяемыми в целом

Мы рассмотрели несколько концепций, включая подход динамической обертки (http://www.codeproject.com/KB/cs/dynamicobjectproxy.aspx#EditableProxy%28implementingIEditableObject%299),, который мы отбросили из-за - нет Intellisense по динамике - нет проверки времени компиляции на динамику - доступ к свойствам при итерации по ним (например, для сеток свойств) очень дорогой

Мы реализовали прототип architectur на рисунке

каждый редактор получает свой собственный клон оригинального объекта. затем он может работать с ним, проверять его и фиксировать в imodelrepository. при этом исходный объект обновляется, и для каждого клона отправляется событие backendchanged. Модели представления других редакторов зарегистрировались для событий, прошедших предварительный обмен, и теперь получают новые клоны, отражающие изменения

положительными аспектами являются: - в imodelrepository выводятся только клоны, прямое редактирование оригинала запрещено - каждый редактор может работать со своим клоном - есть способ уведомить другие клоны и обновить там содержимое, если один редактор фиксирует изменение но негативные аспекты: - каждая модель / редактор Viewer должна искать объект с бэкэнд-обменом, который отправляется в случае изменения исходных объектов. Затем нужно получить новый клон и отказаться от старого - дополнительно каждый редактор / зритель должен искать событие удаления объекта, если другой редактор удалил объект. Затем он должен отказаться от своего клона - требуется много клонов, что замедляет работу системы, особенно при большом количестве одновременно редактируемых объектов

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

Я был бы благодарен за любой вклад или идеи о том, как упростить подход, или о другой архитектуре

ТНХ

Answer 1

• Если несколько редакторов над одним и тем же объектом модели могут быть открыты одновременно,
  тогда ожидание коммита для обновления других было бы нелогичным (*),
  в этом случае я бы использовал одну и ту же виртуальную машину для всех, и позволил бы им редактировать объект и в его промежуточных состояниях, и использовал бы глобальную фиксацию, которая обновляет репозиторий из изменений виртуальной машины.

• Если несколько редакторов над одним и тем же объектом модели НЕ могут быть открыты одновременно,
  тогда одна виртуальная машина (на объект модели) за раз должна.
  Вы можете использовать T4 для генерации класса VM только для чтения для зрителей, который идентичен исходному классу VM, только без установщиков свойств.

(*) Например, Использование может обновить имя, другие зрители / редакторы будут по-прежнему отображать старое имя, пользователь может редактировать имя на два разных значения в двух разных редакторах без фиксации.
Если изменения внесены одним редактором, изменения в другом редакторе могут быть потеряны при повторном редактировании.

• Другой подход состоит в том, чтобы иметь одну виртуальную машину только для чтения для всех зрителей (может быть сгенерирована T4 из виртуальной машины редактора),
  разрешить нескольким редакторам обновлять один и тот же объект модели, использовать параллелизм на основе меток времени (оптимистичный параллелизм) в хранилище и продолжать выделять отдельную виртуальную машину каждому редактору.
  Изменения будут передаваться в репозиторий при фиксации, уже открытые редакторы не будут знать об изменениях, пока не попытаются зафиксировать.
  Когда они пытаются зафиксировать, если объект модели был отредактирован, генерируется исключение (например, OptimisticConcurrencyException в EF), которое вы можете перехватить, чтобы позволить пользователю реагировать на (игнорирование, перезапись, слияние).