Spring Roo + GWT: по-прежнему ли можно использовать RequestFactory, если для каждой операции с данными требуется «двойное управление»? - PullRequest
3 голосов
/ 18 июня 2011

Одним требованием в нашем приложении является реализация «двойного контроля» для всего, включая операции CRUD.Просто чтобы прояснить, «двойной контроль» - это функция, которая требует изменения данных, которые должны быть одобрены кем-то, кроме лица, запрашивающего изменение.Поэтому, когда пользователь вносит изменения в данные, они не фиксируются непосредственно в рабочих таблицах.Мне известно о нескольких способах реализации этого (например, промежуточные таблицы), но это в другой раз.

Вопрос, с таким требованием, считаете ли вы, что мы должны следовать стандартному «центрированному на данных» способу генерирования Roo?+ GWT (который использует RequestFactory)?

Или нам лучше реализовать собственную структуру на основе "шаблона команд" для поддержки двойного управления?

Я склонен к последнему.Моя интуиция (основанная на трехдневной тренировке с Roo + GWT) говорит о том, что RequestFactory не предназначен для двойного контроля, и мы сломаем стену, если попытаемся прорваться. Мы были бы более чем радыбыть здесь ошибочным.

Ответы [ 2 ]

4 голосов
/ 18 июня 2011

Вы смотрели на RequestFactory's ServiceLayerDecorator?Он опосредует все взаимодействие между обработкой полезной нагрузки и объектами и кодом вашего домена.Например, вы можете переопределить методы getProperty и setProperty для чтения и записи в некий «теневой» журнал, содержащий отложенные мутации.

Если вам нужно реализовать ACL для объектов, методыили свойства, методы loadDomainObject и resolveX могут использоваться для управления тем, с какими классами на стороне сервера может взаимодействовать любой данный запрос.

Для подключения к пользовательскому декоратору вы можете создать подкласс RequestFactoryServlet ивызовите конструктор с двумя аргументами.В качестве альтернативы, вы можете просто создать экземпляр SimpleRequestProcessor, используя объект, возвращенный из ServiceLayer.create().

Примечание по реализации: все поведение по умолчанию в домене взаимодействия RequestFactory строится с использованием серии ServiceLayerDecorators;проверьте исходный код GWT, если вы хотите увидеть пример кода для сборки ServiceLayerDecorator.Следует отметить, что если ваш декоратор вызывает какие-либо методы, определенные в ServiceLayer API, он должен использовать экземпляр, предоставленный getTop().Ожидается, что ServiceLayerDecorator экземпляры не будут иметь состояния и могут использоваться повторно, поэтому, если вам необходимо поддерживать состояние при вызовах методов, рассмотрите возможность использования ThreadLocal переменных, аналогично RequestFactoryServlet.getThreadLocalX().

3 голосов
/ 19 июня 2011

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

Если выхочу diffs, потому что RequestFactory только отправляет diff (то есть фактические изменения, внесенные пользователем или вашим кодом в объекты) на сервер, тогда перехват вызовов setProperty, как предложено Бобом, безусловно, является одним из способов сделать это (заставить Боба сделать это).предложение немного яснее: вы бы "сохранили" разность в статическом ThreadLocal, чтобы вы могли получить его из вашего сервисного вызова).Вы также можете использовать «умные» доменные объекты, которые создают внутренний diff при вызове их сеттеров;тогда diff будет доступен для каждого объекта самого объекта.

Если вам нужны моментальные снимки, вам просто нужно реализовать свои сервисы для хранения измененных объектов в «промежуточных таблицах» или в любом другом месте, а не в «производственные столы ";а затем "переместить" их в "производственные таблицы", когда вызывается служба "Одобрить".

Одна вещь, которая понятна (для меня), это то, что вы должны моделировать свои службы и / или объекты вокруг "двойное управление »и не пытайтесь делать это в рамках« простых операций CRUD »(т. е.« сохранить »- это не« сохранить », это« отправить на утверждение »; и есть отдельная операция« одобрить »).

...