2009-09-30 18 views
5

Me han pedido que investigue los enfoques para tratar con una aplicación que se supone que debemos construir. Esta aplicación, hipotéticamente un formulario de Windows escrito en C#, emitirá comandos directamente al servidor si está conectado, pero si la aplicación está fuera de línea, el estado debe mantenerse como si estuviera conectado y luego sincronizar y emitir cambios de datos/comandos para el servidor una vez que es conectado.Opciones de sincronización sin conexión con .NET

No estoy seguro de por dónde empezar a buscar. Esto es algo parecido a Google Gears, pero no creo que tenga esa opción si tomamos una ruta Winform (que parece probable, dado que hay otras funciones que la aplicación necesita que una aplicación web no pueda realizar). ¿Es el Microsoft Sync framework una opción viable? ¿Silverlight hace algo como esto? ¿Alguna otra opción? He buscado en Google un poco, pero me gustaría que la comunidad aporte lo mejor según el escenario.

Respuesta

9

Microsoft Sync Framework definitivamente es compatible con el escenario que describes, aunque diría que es bastante complicado hacerlo funcionar.

Una cosa a entender sobre el Marco de sincronización es que es en realidad dos marcos muy distintos del envío en el mismo paquete:

  • Sync Framework
  • servicios ADO.NET sincronización v 2
.

Los servicios ADO.NET Sync son los más fáciles de configurar, pero están limitados a sincronizar dos almacenes de datos relacionales (aunque puede configurar un servicio web como una fachada remota entre los dos).

El Core Sync Framework no tiene tales limitaciones, pero es mucho más complejo de implementar. Cuando lo usé hace aproximadamente seis meses, descubrí que la mejor fuente para aprender era el SDK, y particularmente el código de muestra de sincronización de archivos/carpetas.

Por lo que pude ver, hubo poco o ningún intercambio de códigos y tipos entre los dos 'frameworks', por lo que tendrá que elegir uno u otro.

En cualquier caso, no hay restricciones sobre cómo alojar el código de sincronización, por lo que Windows Forms es solo una opción entre muchas.

+0

Muy informativo, gracias. – Chris

2

Si entiendo correctamente, esto no me parece un problema real de sincronización de datos en el que desea mantener sincronizadas dos bases de datos. suena más como si quisiera un mecanismo confiable para que un cliente llame a funciones en un servidor en un entorno donde la conexión es inestable, y si la conexión no está presente en ese momento, quiere que se llame a la función tan pronto como la conexión regrese arriba.

Si mi entendimiento es correcto, esta es una opción. si no, esto probablemente no sea útil.


Ésta es una respuesta muy corta a un problema en profundidad, pero que tenía una situación similar y así es como lo manejamos.

Tenemos una aplicación de cliente que necesita para controlar algunos datos en una PC en una tienda. Cuando ocurren ciertos eventos, esta aplicación cliente necesita actualizar nuestro servidor en las oficinas corporativas, preferiblemente en tiempo real. Sin embargo, la conexión no es 100% confiable, por lo que necesitamos un mecanismo similar.

Resolvimos esto tratando de escribir en el servidor a través de un servicio web. Si hay un error al llamar al servicio web, el comando se serializa como un archivo XML en una carpeta llamada "esperando para cargar".

Tenemos una rutina que se ejecuta en nuestra aplicación de cliente en un temporizador establecido para cada n minutos. Cuando el temporizador transcurre, comprueba si hay archivos XML en esta carpeta. Si se encuentra, intenta llamar al servicio web utilizando la información guardada en el archivo, y así sucesivamente hasta que tenga éxito. Tras una llamada exitosa, el archivo XML se elimina.

Suena como un hack-ish, pero era simple de codificar y ha funcionado impecablemente durante cinco años. En realidad ha sido nuestra aplicación más libre de problemas y hemos implementado el patrón en otro lugar con éxito

+0

Interpretación correcta, sí. Estaba pensando en usar MSMQ para que sea un método de fuego y olvido que seguirá intentándolo hasta que llegue, pero es esencialmente lo mismo que tu enfoque. ¡Gracias! – Chris

+0

MSMQ es una buena opción, también. No lo usamos porque no queríamos tener que configurarlo para todos nuestros clientes, y el enfoque que tomamos no implicó ningún paso adicional para el equipo de instalación y los administradores, aunque tomó medidas adicionales en el equipo de desarrollo. . Pero si MSMQ funciona para usted, entonces diría que es una muy buena opción. – David

+0

cualquier cosa puede sugerir ahora. ¿se puede usar msmq en la misma aplicación que llama a api cuando está fuera de línea? ¿Necesito el receptor para msmq? – coder771

Cuestiones relacionadas