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

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

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

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

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

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

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

с. что-то еще

В моем случае сохранение канала данных открытым через LiveCycle RTMP не вариант.

Ответы [ 7 ]

2 голосов
/ 19 октября 2008

а. Подумайте об оптимизации внутренних изменений через прокси-сервер, который делает свое собственное уведомление или опрос: он знает, является ли какая-либо из данных грязной, и быстро вернет (а-ля 304), если нет.

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

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

Приветствия

1 голос
/ 03 апреля 2009

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

1 голос
/ 25 сентября 2008

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

0 голосов
/ 31 марта 2012

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

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

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

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

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

0 голосов
/ 02 октября 2009

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

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

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

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

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

Что я делаю сейчас, так это сохраняю в СЕССИИ ВЫБОР даты и времени. Когда я возвращаюсь для обновления данных, я выбираю, где last_modified> $ SESSION ['lastLoad']

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

Очевидно, вам нужно ОБНОВИТЬ last_modified для каждого ВСТАВКИ и ОБНОВЛЕНИЯ.

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

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

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

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

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

0 голосов
/ 25 сентября 2008

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

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

0 голосов
/ 20 сентября 2008

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

Sam

...