Шаблон проектирования для обновлений клиентского сервера

Question

Я пишу приложение Flex, использующее MVC на стороне клиента. Он использует GraniteDS, а также имеет функции «Удаленная ленивая загрузка и обратная ленивая загрузка».

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

Параметры

1. Обновить модель на клиенте, а затем отправить обновления на сервер. Если сервер выдает ошибку, сообщите об этом пользователю и попросите перезагрузить приложение Flex, поскольку данные теперь не соответствуют фазе. В противном случае предположим, что обновление прошло нормально;
2. Контроллер отправляет данные на сервер после ответа сервера, затем контроллер обновляет модель клиента с обновленными данными. Если ответ сервера не получен, сообщите об ошибке пользователя и попросите перезагрузить приложение, поскольку данные теперь могут быть несовместимыми.

Вариант 2 кажется лучше, но я не уверен, как его реализовать. Какие у меня варианты?

Solutions

1. Клонирование MyUser и отправить клон на сервер, когда сервер возвращает MyUser затем обновить модель. Как бы вы обрабатывали более глубокие вложенные объекты в коллекциях MyUser, поскольку клон копировал бы только оригинальную коллекцию и не клонировал ее?
2. Отослать MyUser.id с сервером с измененными данными. Загрузите MyUser на сервер, используя id, а затем измените их данные. Как только их данные будут изменены на сервере, верните MyUser клиенту, чтобы контроллер мог обновить их модель.

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

Это их лучший способ сделать это?

Answer 1

Если у вас возник конфликт данных при сохранении объекта flex, перезагрузка всего приложения flex - это решение, которое не очень удобно, но оно работает и очень надежно. Для запроса: возможно, вам нужно просто показать сообщение и разрешить клиенту flex повторно отправить запрос (например: проблема с сетью), и он должен быть в большинстве случаев в порядке. Добавьте счетчик, если вам нужно перезапустить приложение после отказа n (вы можете запрограммировать приложение flex для перезагрузки с помощью URLRequest).

О клонировании MyUser: если вы используете базовую сериализацию AMF с ObjectUtil.copy(), она скопирует вложенные поля, поскольку это действительно «глубокая копия» на основе IExternalizable и гранитная сериализация основана на этом. Поэтому ваше решение о клонировании объектов должно работать.

Вы можете использовать гранитипы так, как хотите, например, многие люди предпочитают отключать ленивые функции, даже если они приносят свои проблемы.Я чувствую, что работа с конфликтами данных всегда является обычным делом, не ожидайте, что инфраструктура, даже Гранит, решит все проблемы.