Flex: ¿la mejor estrategia para mantener los datos del cliente sincronizados con la base de datos back-end?

Question

En una aplicación Adobe Flex que utiliza la comunicación remota BlazeDS AMF, ¿cuál es la mejor estrategia para mantener los datos locales actualizados y sincronizados con la base de datos back-end?

En una aplicación web típica, las páginas web actualizan la vista cada vez que se cargan, por lo que los datos de la vista nunca son demasiado antiguos.

En una aplicación Flex, existe la necesidad de cargar más datos por adelantado para compartirlos en pestañas, paneles, etc. Estos datos generalmente se actualizan desde el servidor con menos frecuencia, por lo que hay una mayor posibilidad de que sean obsoleto - lo que provoca problemas al guardar, etc.

Entonces, ¿cuál es la mejor manera de solucionar este problema?

a. compile la aplicación Flex como si fuera una aplicación web: vuelva a cargar los datos de back-end en cada cambio de vista posible

b. ignore el problema y solo resuelva los problemas de datos obsoletos cuando ocurran (a riesgo de molestar a los usuarios que tengan más probabilidades de estar trabajando con datos obsoletos)

c. algo más

En mi caso, mantener el canal de datos abierto a través de LiveCycle RTMP no es una opción.

Answer 1

En el pasado me he ido con la opción "a". Si usaba objetos remotos, podría configurar un poco de lógica de estilo de caché para mantenerlos sincronizados en el extremo remoto.

Sam

Answer 2

No se puede utilizar RTMP través de HTTP (HTTP sondeo)? De esta forma, aún puede usar RTMP, y aunque es mucho más lento que RTMP real, todavía puede desarrollar actualizaciones de esta manera.

Tenemos una aplicación que utiliza RTMP para señalar inserciones, actualizaciones y eliminaciones simplemente mediante la transmisión de mensajes RTMP que contienen el par Table/PrimaryKey, dejando que la aplicación actualice automáticamente sus datos. Hacemos esto a través de Http usando RTMP.

Answer 3

Si no puede usar el protocolo de mensajes en BlazeDS, entonces tendría que aceptar que debe realizar el sondeo de RTMP a través de HTTP. Los datos se comprimen al usar RTMP en AMF, lo que ayuda a agilizar las cosas para que el cliente espere mucho tiempo entre las actualizaciones. Esto también le permitiría escalar más adelante a los métodos push si el cliente del producto decide pagar el hardware y las licencias adicionales.

Answer 4

a. Considere optimizar los cambios de back-end a través de un proxy que haga su propia notificación o poling: sabe si alguno de los datos está sucio y lo devolverá rápidamente (a la a 304) si no es así.

b. A menudo, los usuarios miran más de lo que tocan. Considere un nivel de actualización para buscar y otro cuando comiencen y continúen editando.

Mira BuzzWord: se bloquea en la edición, pero también se guarda y se desbloquea con frecuencia.

Saludos

Answer 5

No es necesario Livecycle y RTMP con el fin de contar con un mecanismo de notificación, puede hacerlo con los canales de BlazeDS y utilizar una de streaming/larga estrategia de votación

Answer 6

me encontré con este artículo acerca de la sincronización:

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

no entró en detalles técnicos, pero se puede adivinar qué tipo de codificación pondrá en práctica estas estrategias.

Tampoco tengo notificaciones sofisticadas de mi servidor, así que necesito estrategias de sincronización.

Por ejemplo, tengo una lista de empresas en mi modelLocator. No cambia muy a menudo, no es lo suficientemente grande como para considerar la paginación, no quiero volver a cargarlo todo (removeAll()) en cada acción del usuario, pero aún así no quiero que la aplicación se cuelgue o ACTUALICE datos corruptos en caso ha sido ACTUALIZADO o ELIMINADO de otra instancia de la aplicación.

Lo que hago ahora es guardar en una SESIÓN el SELECT datetime. Cuando vuelvo a actualizar los datos, SELECCIONO DONDE last_modified> $ SESSION ['lastLoad']

De esta manera obtengo solo filas modificadas después de cargar los datos (la mayoría de las veces 0 filas).

Obviamente necesita ACTUALIZAR last_modified en cada INSERTAR y ACTUALIZAR.

Para DELETE es más complicado. Como el chico señala en su artículo: "¿Cómo podemos enviar un registro que ya no existe?"

Debe indicarle a flex que elemento debe eliminarse (digamos por ID) para que realmente no pueda ELIMINAR sobre ELIMINAR:)

Cuando un usuario elimina una empresa, en su lugar, realiza una ACTUALIZACIÓN: deleted = 1 Luego, en las empresas de actualización, para la fila donde eliminó = 1 simplemente devuelve la ID a flexión para asegurarse de que esta empresa no está en el modelo más.

Por último, pero no menos importante, debe escribir una función que limpie las filas donde deleted = 1 y last_modified sea anterior a ... 3days o lo que crea que se adapte a sus necesidades.

Lo bueno es que si un usuario elimina una fila por error, todavía está en la base de datos y puede guardarla de una eliminación real dentro de 3 días.

Answer 7

En lugar de almacenar en caché en un cliente flexible, ¿por qué no hacer el almacenamiento en caché en el servidor? Algunas de las razones,

1) Cuando caché de datos en el lado del servidor, su centralizado y usted puede hacer que todos los clientes tienen el mismo estado de los datos

2) Hay muchas mejores opciones disponibles en el servidor de almacenamiento en caché en lugar que en flex. También puede tener un trabajo cron que actualice los datos según una frecuencia, por ejemplo, cada 24 horas.

3) A medida que los datos se almacenan en caché en el servidor y que no tiene que buscarla a db cada vez, la comunicación con la flexión será mucho más rápido

Saludos, Tejas