Flex - meilleure stratégie pour synchroniser les données client avec la base de données backend?

Question

Dans une application Adobe Flex utilisant l'accès distant AMF BlazeDS, quelle est la meilleure stratégie pour maintenir les données locales à jour et synchronisées avec la base de données principale?

Dans une application Web classique, les pages Web actualisent la vue à chaque chargement, de sorte que les données de la vue ne sont jamais trop anciennes. Dans une application Flex, il est possible de charger plus de données à l'avance pour les partager entre les onglets, les panneaux, etc. Ces données sont généralement moins souvent actualisées à partir du backend, ce qui augmente les chances de les voir fade - entraînant des problèmes lors de l'enregistrement, etc.

Alors, quelle est la meilleure façon de surmonter ce problème?

a. créez l'application Flex comme s'il s'agissait d'une application Web - rechargez les données du backend à chaque changement d'affichage possible

b. ignorer le problème et traiter les problèmes de données obsolètes quand ils se produisent (au risque d'ennuyer les utilisateurs qui sont plus susceptibles de travailler avec des données obsolètes)

c. autre chose

Dans mon cas, l'ouverture du canal de données via LiveCycle RTMP n'est pas une option.

Answer 1

Dans le passé, je suis allé avec le choix "a". Si vous utilisiez des objets distants, vous pouvez configurer une logique de type cache pour les synchroniser sur l'extrémité distante.

Sam

Answer 2

Tu ne peux pas utiliser RTMP via HTTP (HTTP Polling)? De cette façon, vous pouvez toujours utiliser RTMP, et bien que ce soit beaucoup plus lent que le vrai RTMP, vous pouvez toujours broder les mises à jour de cette façon.

Nous avons une application qui utilise RTMP pour signaler les insertions, les mises à jour et les suppressions en diffusant simplement des messages RTMP contenant la paire Table/PrimaryKey, laissant l'application mettre à jour automatiquement ses données. Nous faisons cela sur Http en utilisant RTMP.

Answer 3

Si vous ne pouvez pas utiliser le protocole de messagerie dans BlazeDS, alors je serais obligé de faire un sondage RTMP sur HTTP. Les données sont compressées lors de l'utilisation de RTMP dans AMF, ce qui permet d'accélérer les choses afin que le client attende longtemps entre les mises à jour. Cela vous permettrait également de passer plus tard aux méthodes push si le client du produit décide de payer pour le matériel et les licences supplémentaires.

Answer 4

a. Pensez à optimiser les modifications back-end via un proxy qui fait sa propre notification ou poling: il sait si l'une des données est sale, et retournera rapidement (a la a 304) sinon.

b. Souvent, les utilisateurs regardent plus qu'ils ne le touchent. Considérez un niveau d'actualisation pour regarder et un autre quand ils commencent et continuent à modifier. Regardez BuzzWord: il se verrouille lors de l'édition, mais enregistre et déverrouille automatiquement automatiquement.

Vive

Answer 5

Vous n'avez pas besoin Livecycle et RTMP afin d'avoir un mécanisme de notification, vous pouvez le faire avec les canaux de BlazeDS et d'utiliser une diffusion en continu/long stratégie de vote

Answer 6

J'ai trouvé cet article sur la synchronisation:

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

Il ne va pas dans les détails techniques, mais vous pouvez deviner quel genre de codage mettra en œuvre ces stratégies.

Je n'ai pas non plus de notifications fantaisie de mon serveur, j'ai donc besoin de stratégies de synchronisation.

Par exemple, j'ai une liste d'entreprises dans mon modelLocator. Il ne change pas souvent, il n'est pas assez grand pour considérer la pagination, je ne veux pas recharger tout (removeAll()) sur chaque action utilisateur mais je ne veux pas que mon application plante ou mette à jour des données corrompues dans cas, il a été mis à jour ou supprimé à partir d'une autre instance de l'application.

Ce que je fais maintenant est d'enregistrer dans une SESSION le datetime SELECT. Quand je reviens pour actualiser les données, je sélectionne last_modified> $ SESSION ['lastLoad']

De cette façon, je ne reçois que des lignes modifiées après avoir chargé les données (la plupart du temps 0 lignes).

De toute évidence, vous devez mettre à jour last_modified à chaque INSERT et UPDATE.

Pour DELETE, c'est plus compliqué. Comme le gars le souligne dans son article: "Comment pouvons-nous envoyer un enregistrement qui n'existe plus"

Vous devez dire à quel élément il doit supprimer (dire par ID) de sorte que vous ne pouvez pas vraiment supprimer sur SUPPRIMER: Lorsqu'un utilisateur supprime une société, vous effectuez une mise à jour à la place: deleted = 1 Ensuite, dans les sociétés de rafraîchissement, pour la ligne où deleted = 1, vous renvoyez simplement l'ID à flex pour vous assurer que cette société n'est pas dans le modèle plus.

Enfin et surtout, vous devez écrire une fonction qui nettoie les lignes où supprimé = 1 et last_modified est plus vieux que ... 3days ou tout ce que vous pensez répondre à vos besoins. La bonne chose est que si un utilisateur supprime une ligne par erreur, il est toujours dans la base de données et vous pouvez l'enregistrer de la suppression réelle dans les trois jours.

Answer 7

Plutôt que de mettre en cache sur le client Flex, pourquoi ne pas effectuer la mise en cache sur le serveur? Quelques raisons,

1) Lorsque vous mettez en cache des données sur le côté du serveur, son centralisée et vous pouvez vous assurer que tous les clients ont le même état des données

2) Il y a beaucoup de meilleures options disponibles sur le côté du serveur pour la mise en cache plutôt que sur flex. En outre, vous pouvez avoir un travail cron qui actualise les données en fonction de certaines fréquences dites toutes les 24 heures.

3) que les données sont mises en cache sur le serveur et il n'a pas besoin de chercher dans db chaque fois, la communication avec flex sera beaucoup plus rapide

Cordialement, Tejas