Flex - лучшая стратегия для хранения данных клиента в синхронизации с базой данных?

Question

В приложении Adobe flex, использующем удаленное управление BlazeDS AMF, что является лучшей стратегией для сохранения локальных данных и синхронизации с базой данных?

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

В приложении Flex есть возможность загружать больше данных вперед для совместного использования между вкладками, панелями и т. Д. Эти данные, как правило, обновляются с бэкэнда реже, поэтому есть большая вероятность того, что он будет устаревшие - приводящие к проблемам при сохранении и т. д.

Итак, что является лучшим способом преодолеть эту проблему?

a. создайте приложение Flex, как если бы оно было веб-приложением, - перезагрузите данные бэкэнд при каждом возможном изменении вида.

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

c. что-то еще

В моем случае сохранение канала данных с помощью LiveCycle RTMP не является вариантом.

Answer 1

В прошлом я пошел с выбором «a». Если вы использовали Remote Objects, вы могли бы настроить некоторую логику в стиле кэша, чтобы синхронизировать их на удаленном конце.

Сэм

Answer 2

Не может использовать RTMP через HTTP (HTTP опрос)? Таким образом, вы все еще можете использовать RTMP, и, хотя он намного медленнее, чем реальный RTMP, вы все равно можете обновлять этот файл.

У нас есть приложение, которое использует RTMP для вставки, обновления и удаления сигналов, просто передавая сообщения RTMP, содержащие пару Table/PrimaryKey, в результате чего приложение автоматически обновляет свои данные. Мы делаем это через Http с помощью RTMP.

Answer 3

Если вы не можете использовать протокол обмена сообщениями в BlazeDS, тогда я должен согласиться с тем, что вы должны делать опрос RTMP по HTTP. Данные сжимаются при использовании RTMP в AMF, что помогает ускорить процесс, поэтому клиент ждет много времени между обновлениями. Это также позволит вам в дальнейшем масштабировать до методов push, если клиент продукта решит заплатить за дополнительное оборудование и лицензии.

Answer 4

a. Рассмотрите возможность оптимизации фоновых изменений через прокси-сервер, который выполняет собственное уведомление или проверку: он знает, загрязнен ли какой-либо из данных, и быстро возвращается (a la a 304), если нет.

b. Часто пользователи смотрят больше, чем трогают. Рассмотрим один уровень обновления для поиска и другой, когда они начинаются и продолжают редактироваться.

Посмотрите на BuzzWord: он блокируется при редактировании, но также автоматически сохраняет и разблокирует часто.

Приветствия

Answer 5

Вам не нужно LiveCycle и RTMP для того, чтобы иметь механизм уведомления, вы можете сделать это с каналами из BlazeDS и использовать потоковый/длинную стратегию опроса

Answer 6

Я нашел эту статью о синхронизации:

http://www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm

Он не вдаваться в технические подробности, но вы можете догадаться, какое кодирование будет реализовывать эту стратегию.

У меня также нет модных уведомлений с моего сервера, поэтому мне нужны стратегии синхронизации.

Например, у меня есть список компаний в моем modelLocator. Он не меняется очень часто, он недостаточно велик, чтобы рассматривать разбиение на страницы, я не хочу перезагружать его (removeAll()) для каждого действия пользователя, но все же я не хочу, чтобы мое приложение вылетало или обновляло поврежденные данные в случае он был ОБНОВЛЕН или удален из другого экземпляра приложения.

Что я сейчас делаю, это сохранение на СЕССИИ SELECT datetime. Когда я возвращаюсь для обновления данных, я выбираю WHERE last_modified> $ SESSION ['lastLoad']

Таким образом, я получаю только строки, измененные после загрузки данных (большую часть времени 0 строк).

Очевидно, вам необходимо ОБНОВИТЬ last_modified для каждого INSERT и UPDATE.

Для DELETE это более сложно. Как заметил парень в своей статье: «Как мы можем отправить запись, которая больше не существует»

Необходимо указать, какой элемент должен удалить (например, по идентификатору), чтобы вы не смогли УДАЛИТЬ на DELETE:)

Когда пользователь удаляет компанию, вы делаете ОБНОВЛЕНИЕ вместо: deleted = 1 Затем в обновленных компаниях для строки, где удалено = 1, вы просто отправляете обратно идентификатор в flex, чтобы убедиться, что эта компания не является в модели больше.

И последнее, но не менее важное: вам нужно написать функцию, которая очищает строки, где deleted = 1 и last_modified старше, чем ... 3 дня или что бы вы ни думали в соответствии с вашими потребностями.

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

Answer 7

Вместо кэширования на гибком клиенте, почему бы не сделать кеширование на стороне сервера? Некоторые причины,

1) При кэшировании данных на стороне сервера, его централизованные и вы можете убедиться, что все клиенты имеют одинаковое состояние данных

2) Есть гораздо лучшие варианты, доступные на стороне сервера для кэширования, а чем на flex. Также вы можете выполнить задание cron, которое обновляет данные на основе определенной частоты каждые 24 часа.

3) Поскольку данные кэшируются на сервере и не нужно извлекать его из БД каждый раз, общение с прогибается будет намного быстрее

С уважением, Tejas