Zugreifen auf Metadaten von Komponenten anderer Versionen
Der Metadaten-Speicherdienst speichert Replikat- und Elementmetadaten in einer vereinfachten Datenbank. Die Metadaten werden in einem bestimmten Tabellenschema und Binärformat gespeichert, die sich bei der Veröffentlichung neuer Versionen von Sync Framework ändern können. Darüber hinaus ändern sich möglicherweise benutzerdefinierte Anbieterfelder in der Datenbank, wenn ein Entwickler neue Versionen eines bestimmten Anbieters freigibt. Um eine bessere Interoperabilität zwischen verschiedenen Versionen zu ermöglichen, stellt Sync Framework ein kanonisches Dateiformat und die SyncMetadataStoreSerializer-Klasse (für verwalteten Code) bzw. die ISyncMetadataStoreSerializer-Schnittstelle (für nicht verwalteten Code) bereit. Diese sind in einem angemessenen Bereich von Metadatenänderungen zwischen verschiedenen Versionen aufwärts- und abwärtskompatibel.
Sync Framework bietet auch Unterstützung für die Aktualisierung des Metadatenspeichers. Weitere Informationen finden Sie unter Aktualisieren der Metadatenspeicherversion.
Verwenden des kanonischen Formats für Versionskompatibilität
Einer der Hauptvorteile eines kanonischen Formats ist, dass partielle Teilnehmerreplikate, z. B. Geräte, mit anderen Versionen eines Anbieters synchronisiert werden können. Betrachten wir dazu folgendes Beispiel:
Eine Anwendung unterstützt die Synchronisierung zwischen einem Gerät und einer Reihe von Servern in verschiedenen Büros eines Unternehmens. Benutzer können Geräte mit Servern synchronisieren, Änderungen auf den Geräten vornehmen, Synchronisierungen mit Servern in anderen Büros durchführen usw.
Der Kontakte-Anbieter des Unternehmens wurde in drei verschiedenen Versionen bereitgestellt: 1.0, 2.0 und 2.5. Version 1.0 basiert auf Sync Framework 1.0, und die beiden anderen Versionen basieren auf Sync Framework 2.0. Alle drei Versionen sind weiterhin im Unternehmensnetzwerk verfügbar und werden unterstützt.
Sync Framework-Versionsverwaltung
Wenn die Anwendung Metadaten auf dem Gerät in einer Metadaten-Speicherdienst-Binärdatei speichert, sind Metadatenschema und -format möglicherweise nicht mit dem Anbieter kompatibel, mit dem ein Benutzer die Synchronisierung durchführen möchte. Diese Inkompatibilität kann aus zwei Gründen entstehen: Entweder weist der Anbieter eine andere Version auf und verwendet ein anderes Metadatendateiformat, oder er verwendet eine andere Version von Sync Framework. Um dieses Problem zu vermeiden, kann die Anwendung stattdessen auf jedem Server eine Binärdatei verwenden und anschließend die Metadaten zwischen dieser Datei und einer kanonischen Datei auf jedem Gerät serialisieren und deserialisieren. Der Prozess sieht folgendermaßen aus:
Nach Abschluss der ersten Synchronisierungssitzung für ein Gerät serialisiert die Anwendung Metadaten in eine kanonische Datei auf dem Gerät, indem sie SerializeReplicaMetadata (für verwalteten Code) oder ISyncMetadataStoreSerializer::SerializeReplicaMetadata (für nicht verwalteten Code) aufruft.
Während jeder nachfolgenden Sitzung führt die Anwendung folgende Aktionen aus:
Ruft DeserializeReplicaMetadata (für verwalteten Code) oder ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (für nicht verwalteten Code) auf, um Metadaten aus der kanonischen Datei zu deserialisieren und in der Binärdatei auf dem Server zu übernehmen.
Synchronisiert Änderungen zwischen dem Gerät und dem Server.
Ruft SerializeReplicaMetadata (für verwalteten Code) oder SerializeReplicaMetadata (für nicht verwalteten Code) auf, um aktualisierte Metadaten zurück auf das Gerät zu serialisieren.
Die Serialisierungs- und Deserialisierungsprozesse sind effizient: Für die Serialisierung werden die Abfragen indiziert, die Metadaten aus dem Speicher des Metadaten-Speicherdiensts auswählen, und für die Deserialisierung werden nur inkrementelle Änderungen an der kanonischen Datei deserialisiert.
Anbieterversionsverwaltung
Die Methoden der SyncMetadataStoreSerializer-Klasse (für verwalteten Code) und der ISyncMetadataStoreSerializer-Schnittstelle (für nicht verwalteten Code) unterstützen die Anbieterversionsverwaltung, indem sie die Anbieterversion als Teil der Metadaten serialisieren und die erwartete Anbieterversion beim Deserialisieren der Metadaten überprüfen. Nehmen Sie das folgende Szenario als Beispiel:
Es gibt drei Versionen eines Anbieters (v1, v2 und v3).
In v2 wurde am benutzerdefinierten Schema für den Anbieter eine nicht kompatible Änderung vorgenommen.
v2 und v3 sind kompatibel.
Wenn Sie Metadaten von einem v3-Anbieter serialisieren, können Sie in den Metadaten den Wert v2 als Anbieterversion angeben. Anschließend kann ein v2- oder v3-Anbieter Metadaten deserialisieren, indem er den Wert v2 als erwarteten Versionsparameter für die Anbieterkompatibilität angibt. Der v1-Anbieter würde einen Wert aus v1 angeben, und die Deserialisierung würde programmbedingt fehlschlagen, da die Metadaten nicht mit v1 kompatibel sind. Verwenden Sie generell eine möglichst niedrige Version, um den größten Kompatibilitätsgrad mit früheren Versionen des gleichen Anbieters sicherzustellen.
Wenn Sie eine neue Version eines Anbieters freigeben, der das Metadatenschema aktualisiert, müssen Sie darauf achten, die Kompatibilität der Metadaten mit früheren Anbieterversionen aufrechtzuerhalten. Weitere Informationen finden Sie unter Aktualisieren der Metadatenspeicherversion.