Compartilhar via


Acessando metadados em componentes com versões diferentes

O serviço de armazenamento de metadados armazena metadados de réplica e de item em um banco de dados leve. Os metadados são armazenados em um esquema de tabela específico e em um formato binário que podem sofrer alterações à medida que novas versões do Sync Framework são liberadas. Além disso, os campos de provedor personalizado no banco de dados podem ser alterados à medida que um desenvolvedor libera novas versões de um provedor específico. Para permitir melhor interoperabilidade entre as diferentes versões, o Sync Framework fornece um formato de arquivo canônico e a classe SyncMetadataStoreSerializer (para código gerenciado) ou a interface ISyncMetadataStoreSerializer (para código não gerenciado), que são compatíveis com versões posteriores e anteriores, em um intervalo razoável de alterações de metadados entre as versões.

O Sync Framework também dá suporte para atualização do repositório de metadados. Para obter mais informações, consulte Atualizando a versão do repositório de metadados.

Usando o formato canônico para compatibilidade de versão

Um dos principais benefícios de um formato canônico é a capacidade sincronização das réplicas participantes parciais, como dispositivos, com versões diferentes de um provedor. Considere o exemplo a seguir:

  • Um aplicativo dá suporte para sincronização entre um dispositivo e vários servidores em diversos escritórios corporativos. Os usuários podem sincronizar um dispositivo com um servidor, fazer alterações no dispositivo, sincronizar com um servidor em outro escritório, e assim por diante.

  • O provedor de contatos da empresa foi liberado em três versões diferentes: 1.0, 2.0 e 2.5. A versão 1.0 baseia-se no Sync Framework 1.0 e as outras duas versões baseiam-se no Sync Framework 2.0. As três versões ainda estão disponíveis e têm suporte na rede corporativa.

Controle de versão do Sync Framework

Se o aplicativo armazenar metadados em um arquivo binário do serviço de armazenamento de metadados no dispositivo, o esquema e o formato dos metadados poderão ser incompatíveis com o provedor com o qual um usuário deseja sincronizar. Essa incompatibilidade pode ocorrer porque o provedor é uma versão diferente e usa um formato de arquivo de metadados diferente ou porque o provedor usa uma versão diferente do Sync Framework. Para evitar esse problema, o aplicativo pode usar um arquivo binário em cada servidor e então serializar e desserializar os metadados entre esse arquivo e um arquivo canônico em cada dispositivo. O processo é o seguinte:

  1. Quando a primeira sessão de sincronização de um dispositivo é concluída, o aplicativo serializa os metadados para um arquivo canônico no dispositivo chamando SerializeReplicaMetadata (para código gerenciado) ou ISyncMetadataStoreSerializer::SerializeReplicaMetadata (para código não gerenciado).

  2. Durante cada sessão subsequente, o aplicativo executa as seguintes ações:

    1. Chama DeserializeReplicaMetadata (para código gerenciado) ou ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (para código não gerenciado) para desserializar os metadados do arquivo canônico e aplicá-los ao arquivo binário no servidor.

    2. Sincroniza as alterações entre o dispositivo e o servidor.

    3. Chama SerializeReplicaMetadata (para código gerenciado) ou SerializeReplicaMetadata (para código não gerenciado) para serializar os metadados atualizados novamente para o dispositivo.

Os processos de serialização e desserialização são eficientes: para serialização, as consultas que selecionam os metadados do repositório do serviço de armazenamento de metadados são indexadas; para desserialização, apenas as alterações incrementais do arquivo canônico são desserializadas.

Controle de versão do provedor

Os métodos da classe SyncMetadataStoreSerializer (para código gerenciado) e da interface ISyncMetadataStoreSerializer (para código não gerenciado) dão suporte para o controle de versão do provedor serializando a versão do provedor como parte dos metadados e verificando a versão do provedor esperada quando os metadados são desserializados. Considere o seguinte cenário:

  • Há três versões de um provedor (v1, v2 e v3).

  • Na v2, uma alteração incompatível foi feita no esquema personalizado do provedor.

  • A v2 e a v3 são compatíveis.

Se você serializar os metadados de um provedor v3, poderá especificar um valor v2 para a versão do provedor nos metadados. Um provedor v2 ou v3 poderá então desserializar os metadados especificando um valor v2 para o parâmetro esperado de versão de compatibilidade do provedor. O provedor v1 especifica um valor v1 e a desserialização falha por design porque os metadados são incompatíveis com a v1. Em geral, use a versão mais baixa possível para assegurar o nível mais alto de compatibilidade com versões anteriores do mesmo provedor.

Ao liberar uma nova versão de um provedor que atualiza o esquema de metadados, você deve tomar cuidado para manter a compatibilidade dos metadados com versões anteriores do provedor. Para obter mais informações, consulte Atualizando a versão do repositório de metadados.

Consulte também

Outros recursos

Sync Framework Metadata Storage Service