Flex - лучшая стратегия для синхронизации клиентских данных с серверной базой данных?
В приложении Adobe Flex, использующем удаленное взаимодействие BlazeDS AMF, какова наилучшая стратегия сохранения локальных данных в актуальном состоянии и в синхронизации с серверной базой данных?
В типичном веб-приложении веб-страницы обновляют представление каждый раз при загрузке, поэтому данные в представлении никогда не будут слишком старыми.
В приложении Flex существует соблазн предварительно загрузить больше данных для совместного использования на вкладках, панелях и т. д. Эти данные обычно обновляются из серверной части реже, поэтому существует большая вероятность того, что они устарели, что приведет к проблемы при сохранении и т. д.
Итак, как лучше всего решить эту проблему?
а. создать приложение Flex, как если бы это было веб-приложение - перезагружайте данные серверной части при каждом возможном изменении представления
б. игнорируйте проблему и просто решайте проблемы с устаревшими данными, когда они возникают (с риском раздражения пользователей, которые с большей вероятностью будут работать с устаревшими данными)
c. что-то другое
В моем случае сохранение канала данных открытым через LiveCycle RTMP не вариант.
Ответы 7
Раньше я выбирал "а". Если вы использовали удаленные объекты, вы могли бы настроить некоторую логику в стиле кеша, чтобы они синхронизировались на удаленном конце.
Сэм
Разве вы не можете использовать RTMP через HTTP (HTTP-опрос)? Таким образом, вы по-прежнему можете использовать RTMP, и хотя он намного медленнее, чем настоящий RTMP, вы все равно можете транслировать обновления таким образом.
У нас есть приложение, которое использует RTMP для сигнализации вставки, обновления и удаления, просто транслируя RTMP-сообщения, содержащие пару Table / PrimaryKey, оставляя приложение для автоматического обновления своих данных. Мы делаем это по Http с использованием RTMP.
Если вы не можете использовать протокол обмена сообщениями в BlazeDS, я должен согласиться, что вам следует выполнять опрос RTMP через HTTP. При использовании RTMP в AMF данные сжимаются, что помогает ускорить процесс, поэтому клиент долго ждет между обновлениями. Это также позволит вам в дальнейшем масштабироваться до методов push, если заказчик продукта решит заплатить за дополнительное оборудование и лицензии.
а. Подумайте об оптимизации внутренних изменений с помощью прокси, который выполняет собственное уведомление или опрос: он знает, являются ли какие-либо данные грязными, и быстро вернется (а-ля 304), если нет.
б. Часто пользователи выглядят больше, чем касаются. Рассмотрите один уровень обновления для просмотра и другой, когда они начнут и продолжат редактирование.
Посмотрите на BuzzWord: он блокируется при редактировании, но также часто автоматически сохраняет и разблокирует.
Ваше здоровье
Вам не нужны Livecycle и RTMP, чтобы иметь механизм уведомлений, вы можете сделать это с помощью каналов от BlazeDS и использовать стратегию потоковой передачи / длительного опроса
Я нашел эту статью о синхронизации:
http://www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm
Здесь не рассматриваются технические подробности, но вы можете догадаться, какой тип кода реализует эту стратегию.
У меня также нет причудливых уведомлений с моего сервера, поэтому мне нужны стратегии синхронизации.
Например, у меня есть список компаний в моем modelLocator. Он не очень часто меняется, он недостаточно велик, чтобы учитывать разбиение на страницы, я не хочу перезагружать его все (removeAll ()) при каждом действии пользователя, но все же я не хочу, чтобы мое приложение вылетало или ОБНОВЛЯТЬ поврежденные данные в если он был ОБНОВЛЕН или УДАЛЕН из другого экземпляра приложения.
Сейчас я сохраняю в СЕССИИ дату и время SELECT. Когда я возвращаюсь для обновления данных, я ВЫБИРАЮ WHERE last_modified> $ SESSION ['lastLoad']
Таким образом, я получаю только строки, измененные после загрузки данных (в большинстве случаев 0 строк).
Очевидно, вам нужно UPDATE last_modified для каждого INSERT и UPDATE.
Для DELETE это сложнее. Как отмечает парень в своей статье: «Как мы можем отправить запись, которой больше не существует»
Вам нужно указать flex, какой элемент он должен удалить (скажем, по идентификатору), чтобы вы не могли УДАЛИТЬ при УДАЛЕНИИ :)
Когда пользователь удаляет компанию, вы вместо этого выполняете ОБНОВЛЕНИЕ: удалено = 1 Затем при обновлении компаний для строки, в которой удалено = 1, вы просто отправляете обратно идентификатор для гибкости, чтобы убедиться, что эта компания больше не участвует в модели.
И последнее, но не менее важное: вам нужно написать функцию, которая очищает строки, где удаленный = 1 и last_modified старше, чем ... 3 дня или как вы думаете, что соответствует вашим потребностям.
Хорошо то, что если пользователь по ошибке удаляет строку, она все еще находится в базе данных, и вы можете сохранить ее от реального удаления в течение 3 дней.
Почему бы не кэшировать на стороне сервера вместо кеширования на гибком клиенте? Некоторые причины,
1) Когда вы кешируете данные на стороне сервера, они централизованы, и вы можете убедиться, что все клиенты имеют одинаковое состояние данных
2) На стороне сервера доступны гораздо лучшие варианты кеширования, чем на гибком. Также у вас может быть задание cron, которое обновляет данные с определенной периодичностью, скажем, каждые 24 часа.
3) Поскольку данные кэшируются на сервере, и нет необходимости каждый раз извлекать их из базы данных, связь с Flex будет намного быстрее.
С уважением, Теджас