Chapitre II : Synchronisation manuelle, personnalisation. , Page 2

Chapitre II : Synchronisation manuelle, personnalisation.

Après une introduction à Sync. Services for ADO.NET 2.0, nous allons construire aujourd'hui un ensemble de classes, sans passer par le designer, pour créer un système de synchronisation en nous appuyant sur Microsoft Synchronization Framework (MSF).

Par Sébastien Pertus publié le 13/01/2008 à 22:50, lu 4834 fois, 6 pages

4 commentaire(s) tag(s)

Tags: SQL Server 2005, Microsoft Sync Framework, Visual Studio 2008, ADO.NET 2

2 | Présentation

1 | Introduction

2 | Présentation

3 | Mise en place : Source de données

4 | Première solution

5 | Deuxième solution

6 | Conclusion

Téléchargez le code source - 552 Kb

Présentation

Pour commencer, nous devons bien savoir ce que nous devons créer.
Voici un schéma de l'architecture que nous devons reproduire :

/content/61a8af9e-e912-4557-b7c5-17e0734e14d7/SchemaGeneral.jpg

Et dans un soucis de compréhension (et pour préparer les prochains articles) je vais ici dissocier deux choses :

Tout d'abord la partie "Serveur" : Il s'agit de l'ensemble des classes de synchronisation serveur, ainsi que les SyncAdapters , un pour chaque SyncTable.
Nous verrons dans un prochain article que c'est cette partie, dans une architecture N-Tiers WCF, qui serait portée par notre service remote.
La partie "Cliente" : Il s'agit de l'ensemble des classes de synchronisation de la source de données cliente et l'agent de synchronisation configuré avec les SyncTables.
Dans notre architecture N-Tiers, il s'agirait ici de la partie embarquée dans le client.

Pour la partie Cliente, nous pouvons la représenter sous la forme :

/content/61a8af9e-e912-4557-b7c5-17e0734e14d7/SchemaClient.jpg

Nous avons notamment :

Le Client Sync Provider : Nous connaissons déjà le fournisseur de synchronisation client, il s'agit du fournisseur de synchronisation Sql Ce, j'ai nommé SqlCeClientSyncProvider.
Ce fournisseur de synchronisation dispose d'un ensemble de méthodes internes de création des tables, de requêtage incrémental et de stockage des métadatas nécessaires à notre synchronisation.
Le SyncAgent : Il est le coordinateur de notre synchronisation. Il doit notamment connaitre le fournisseur de synchronisation client, le fournisseur de synchronisation serveur, ainsi que les tables à synchroniser.
Les SyncTables : Il s'agit de l'ensemble des définitions des tables à synchroniser, plus les options de synchronisation (Direction, Création etc...). Ces SyncTables peuvent être liées dans un SyncGroup, conteneur garantissant un contexte de transaction ainsi qu'une mise à jour respectueuse des clés externes.

Pour la partie serveur, nous pouvons la représenter sous la forme :

/content/61a8af9e-e912-4557-b7c5-17e0734e14d7/SchemaServeur.jpg

Nous avons notamment :

Le Server Sync Provider : Ce fournisseur de synchronisation serveur existe déjà, il s'agit du DbServerSyncProvider.
Ce DbServerSyncProvider a l'avantage de pouvoir se connecter à n'importe quelle source de donnée de type ADO.NET; par contre il a les inconvénients de son avantage, il est à configurer entièrement, au contraire du provider client SqlCeClientSyncProvider, qui lui est déjà configuré, mais qui n'accède qu'à une source de type Sql Ce.
Les SyncAdapters : On peut faire une comparaison du SyncAdapter avec le TableAdapter. Le SyncAdapter contient une commande permettant d'effectuer une opération (SQL) sur une source de données proposée par le DbServerSyncProvider.
Chaque DbServerSyncProvider possède plusieurs SyncAdapters, un par table (enfin, par SyncTable !)
Chaque SyncAdapter possède plusieurs commandes (DbCommand) lui permettant de requêter la source de données.
La liste de ces commandes, au nombre de 8:
- InsertCommand: Il s'agit de la commande permettant d'insérer les données coté serveur.
- DeleteCommand: Il s'agit de la commande permettant de supprimer les données. Attention, il ne s'agit pas d'un "simple" Delete, cette commande doit savoir gérer les conflits, et forcer la suppression si nécessaire (cas où le client l'emporte lors du traitement du conflit).
- UpdateCommand: Il s'agit de la commande permettant de mettre à jour les données. Comme la commande DeleteCommand, cette commande est soumise à la gestion des conflits et le forçage de la mise à jour.
- SelectConflictDeletedRowsCommand: Lors d'un conflit, cette commande récupére les informations de la ligne supprimée côté serveur, pour nous permettre de gérer le conflit, et ordonner l'opération de forçage de la suppression ou non.
- SelectConflictUpdatedRowsCommand: Lors d'un conflit, cette commande récupére les informations de la ligne mise à jour côté serveur, pour nous permettre de gérer le conflit, et ordonner l'opération de forçage de la mise à jour ou non.
- SelectIncrementalInsertsCommand: Commande permettant de récupérer les nouveaux enregistrements insérés dans la source de données serveur depuis la dernière synchronisation
- SelectConflictUpdatedRowsCommand: Commande permettant de récupérer les enregistrements mis à jour sur la source de données serveur depuis la dernière synchronisation
- SelectIncrementalDeletesCommand: Commande permettant de récupérer les enregistrements supprimés de la source de données serveur depuis la dernière synchronisation
Nous verrons dans la prochaine partie qu'il existe un objet, le SqlSyncAdapterBuilder, qui va nous permettre de générer l'ensemble des ces requêtes, pour chaque SqlSyncAdapter.