Compartir a través de

Implementar y controlar las versiones de aplicaciones

En este tema se describe la implementación y el control de versiones de las aplicaciones cliente y servidor. Para obtener información sobre la inicialización de bases de datos del mismo nivel, vea "Inicializar una base de datos servidor" en Configurar y ejecutar la sincronización de colaboración (no SQL Server).

La forma de implementar una aplicación cliente y servidor que usa Sync Framework depende de si la aplicación es de 2 niveles o de n niveles. En una aplicación de dos niveles, todo el código de sincronización está en el cliente, y la aplicación puede implementarse como cualquier otra aplicación basada en SQL Server Compact. Normalmente, la implementación implica usar ClickOnce para publicar la aplicación o empaquetarla y después copiarla en cada cliente. Para obtener más información acerca de cómo implementar aplicaciones que usen SQL Server Compact, vea los temas " Implementar aplicaciones" y "Crear e implementar una aplicación en un escritorio" en los Libros en pantalla de SQL Server Compact. En una aplicación n-tier, también debe implementar un código en el equipo que hospeda los componentes de sincronización del servidor.

Crear e inicializar la base de datos cliente

Para las aplicaciones de dos niveles y n-tier (n niveles), debe decidir cómo desea crear e inicializar la base de datos cliente que contiene el esquema y los datos que requiere la aplicación. Hay dos enfoques principales:

  • Usar Sync Framework para crear la base de datos, y descargar el esquema de tablas y los datos durante la primera sincronización. Este es el método más sencillo. No obstante, puede que requiera una gran cantidad de tráfico de red y procesamiento del servidor, si hay muchos clientes y el conjunto de datos es extenso.

  • Crear previamente la base de datos que contiene el esquema de tablas y un conjunto de datos inicial. La aplicación cliente puede transportar o descargar la base de datos, que tiene la forma de un archivo .sdf. Si la aplicación descarga cambios incrementales, puede actualizar la base de datos cliente durante la primera sincronización. Si sigue este método, establezca la propiedad CreationOption en un valor apropiado.

    Si la aplicación incluye cargas y desea saber cuál es su origen, la aplicación puede establecer la propiedad ClientId de forma que identifique de manera inequívoca la base de datos cliente en el servidor; o Sync Framework generará un identificador nuevo para la base de datos.

    Nota

    La creación previa de la base de datos cliente no es apropiada para aquellas aplicaciones en las cuales el filtro aplicado a los datos sea diferente en cada cliente. Podrían perderse cambios durante la sincronización inicial.

Para obtener más información acerca de cómo inicializar la base de datos cliente, vea Inicializar la base de datos cliente y trabajar con el esquema de tablas.

Control de versiones de aplicaciones

Después del desarrollo y la implementación de una aplicación, podrían desarrollarse nuevas versiones. El control de versiones de las aplicaciones requiere tener en cuenta dos áreas:

  • Las partes de la aplicación afectadas por una versión nueva

  • Si la nueva versión debe coexistir o no con versiones anteriores

Normalmente, una aplicación n-tier se actualiza con más facilidad en Sync Framework porque se pueden actualizar los componentes del servidor con independencia de los componentes del cliente. Esto le permite exponer un servicio nuevo que incluya la funcionalidad actualizada y que proteja a los clientes de los cambios del servidor hasta que estén listos para hacer que se actualicen los componentes del cliente.

Control de versiones en aplicaciones n-tier

Para Sync Framework, la actualización principal de las aplicaciones que hay que considerar es un cambio de esquema en la base de datos servidor. Sync Framework no propaga automáticamente los cambios de esquema desde el servidor al cliente. No obstante, admite los cambios de esquema, siempre y cuando se actualicen las partes apropiadas de la aplicación. Para obtener una lista de los cambios de esquema que se admiten en la base de datos cliente, vea Trabajar con esquemas de tablas. Si se efectúa un cambio de esquema en la base de datos servidor, en primer lugar se debe decidir si hay necesidad de propagarlo al cliente. Por ejemplo, si agrega una columna de tarjeta de crédito a una tabla de la base de datos servidor, pero una regla de empresa prohíbe a los empleados obtener información de tarjetas de crédito sin conexión, no será necesario propagar el cambio de esquema al cliente. Si decide propagar el cambio de esquema, la forma de hacerlo dependerá del tipo de cambio.

Cambios de esquema habituales

Los dos cambios de esquema más frecuentes consisten en agregar una columna a una tabla existente y agregar una tabla nueva, o decidir la inclusión de una tabla existente que originalmente no formaba parte de la aplicación. Si la aplicación requiere la sincronización de una tabla nueva, debe agregar un SyncAdapter a la tabla. Después de la actualización de los componentes del servidor, la aplicación cliente o el usuario de la aplicación pueden determinar si se debe sincronizar la nueva tabla. Si se toma la decisión de sincronizarla, se deberán cambiar los componentes del cliente para que incluyan una SyncTable para la nueva tabla. Estos cambios deben transmitirse a cada aplicación cliente de alguna manera. La tecnología ClickOnce permite publicar actualizaciones de las aplicaciones, y las aplicaciones pueden comprobar si existen actualizaciones antes de su inicio. Si agrega una columna nueva a una tabla y desea sincronizar la columna, debe agregarla a la base de datos cliente y actualizar los comandos que sincronizan los cambios. Para los cambios de esquema que no sean agregar una columna nueva, elimine la tabla en el cliente y vuelva a crearla por medio de Sync Framework u otro mecanismo.

Versiones coexistentes

En algunos escenarios, puede que las versiones nueva y antigua de una aplicación cliente tengan que coexistir. En estos casos, puede aplicar dos métodos:

  • Mantener varias versiones de los componentes del servidor, para que las versiones anteriores de los componentes del cliente puedan seguir teniendo acceso a la versión apropiada de los componentes del servidor. La mejor manera de enfocar el control de la versión es exponer un servicio nuevo con funcionalidad actualizada. Los clientes podían actualizarse utilizando la tecnología ClickOnce. Cuando la actualización se completara, el cliente se redirigiría al nuevo servicio web.

  • Diseñar los componentes del cliente y del servidor de forma que usen un parámetro de versión de la aplicación. Este enfoque permite que la aplicación cliente notifique al servidor la versión que espera. En el ejemplo siguiente, el procedimiento almacenado que selecciona inserciones del servidor acepta un parámetro @appversion. Se agrega un parámetro a SelectIncrementalInsertsCommand y después se suministra un valor por medio de un SyncParameter en el SyncAgent. Cuando se realiza la sincronización, se transmite la versión de la aplicación al servidor y el procedimiento almacenado selecciona la versión correcta del esquema de la tabla.

    this.Configuration.SyncParameters.Add(
      new SyncParameter("@appversion", 1));
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int);

Me.Configuration.SyncParameters.Add( _
      New SyncParameter("@appversion", 1))
customerIncrUpdates.Parameters.Add("@appversion", SqlDbType.Int); 

CREATE PROCEDURE usp_CustomerSelectIncrementalInserts(
    @sync_last_received_anchor timestamp, 
    @sync_new_received_anchor timestamp, 
    @appversion int
)

AS
    IF @appversion = 1
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE IF @appversion = 2
    BEGIN
        SELECT CustomerId, CustomerName, SalesPerson, CustomerType
        FROM Sales.Customer 
        WHERE InsertTimestamp > @sync_last_received_anchor 
        AND InsertTimestamp <= @sync_new_received_anchor
    END
    ELSE
    BEGIN
        PRINT('Unrecognized version')
        RETURN
    END

Vea también

Conceptos

Arquitectura y clases para la sincronización del cliente y el servidor
Consideraciones sobre el diseño y la implementación de aplicaciones

  • Last updated on